The most secure file is the one you never upload.
LittlePDF was built with a privacy-first architecture. Half the toolkit runs in your browser, which removes the upload, the server-side copy, and the whole class of risk that comes with them. The rest of this page is about the tools that cannot.
Our Transparent Processing Model
Three tiers across 36 tools. Each tier handles your file differently, and this is exactly what each one does. The full tool-by-tool breakdown is below.
1. Client-Side Tools
18 ToolsThe core tools (merge, split, compress, watermark, edit) run entirely locally. Your file never leaves your browser. The table below names all 18 of them.
Processing: pdf-lib and pdfjs, in the page
Network activity: no request carries the file
File storage: in memory, gone when the tab closes
2. Server Conversions
7 ToolsFor complex conversions (like PDF to Word), files are routed to our Gotenberg microservices over an encrypted connection. Our route holds it in memory, the conversion engine opens it inside its own container, and we keep no copy once the result is on its way back to you.
Processing: Ephemeral Containers
Network Activity: TLS 1.3 Encrypted
Retention by us: none
3. AI Intelligence
11 ToolsPowered by Claude and Gemini APIs. Data is transmitted securely and strictly opted out of AI model training.
Processing: API Edge Connect
Model Training: Disabled by Contract
Retention by us: none
Every tool, and where it runs
All 36 tools, named. 18 of them never send your file anywhere. The other 18 upload it, because 7 of them need a conversion engine we cannot ship into a browser tab and 11 of them need a model that does not live on your machine. A page that only listed the first group would be telling you half of it.
This table is generated from the same tool registry the app itself reads, so it cannot drift away from what the code actually does.
For the 18 that upload: the file travels over TLS, our route holds it in memory for the length of the request, and we keep no copy once the result is on its way back to you. That is a promise rather than something you can watch, which is why the next section is about the 18 you can watch.
Prove it in your own browser
Nobody should take a privacy claim on trust, ours included. Here are two checks that take about a minute each and settle the question without involving us. Run them on a file you do not mind losing, and use a document with recognisable text so you can search the request bodies for it.
A browser tool sends nothing
- Open Merge PDF and let the page finish loading.
- Open Developer Tools with F12, or Cmd+Option+I on a Mac, and go to the Network tab.
- Click the clear button so the panel is empty, then tick Preserve log so nothing is discarded.
- Filter to Fetch/XHR. That is where an upload would appear.
- Drop in two PDFs and run the merge. Save the result when it downloads.
- Read the list. No request carries your PDF. That is the claim, and it is the one to check. The merge ran in the page through pdf-lib, so there is nothing to upload.
- Sort by size. That is the fastest confirmation: your file is megabytes, and nothing leaving the page comes close. Whatever you do see is kilobytes of counters and diagnostics.
- Expect some entries, and know what they are. A call to
/api/usage/anonymouscounts the run against your daily allowance. Error and performance telemetry may also appear, going to Sentry, Google Tag Manager, and Vercel Speed Insights. None of them is handed your document. If you want to be strict about it, click any entry and read its request payload: the PDF is not in there.
The stronger version of this test: run one merge online, then disconnect and run a second. It still works, because the processing code is now cached in your browser and there was never a server in the loop. It has to be the second merge; the first one fetches the pdf-lib worker, which is why a browser that has never run this tool needs one online pass before it can do it offline.
A conversion sends exactly one request
- Open PDF to Word with the Network tab open and filtered the same way.
- Upload a PDF and run the conversion.
- Find the single POST to
/api/convert. Its size will be roughly your file's size, because it is your file. - Check the protocol column, or the Security tab for that request. It is HTTPS, so the body is encrypted in transit and no intermediary reads it.
- Count the requests. One upload, one response with the converted file. There is no second call sending your document anywhere else.
This is the honest half of the story. For these 18 tools, what happens after that POST is something we tell you rather than something you can watch: the file is held in memory for the request, handed to the conversion engine or the model, and not written to storage.
What the two checks do and do not settle
They settle the architecture, which is the part that matters most and the part most privacy pages leave you to take on faith. A tool that never issues a request cannot leak a file, and no policy change on our side can retroactively upload something we never received. What the checks cannot settle is our conduct on the 18 tools that do upload. For those you are trusting a stated practice, so we keep the statement narrow and specific rather than absolute: transport is encrypted, the file lives in memory for the length of the request, we write no copy to storage, and the AI providers process under terms that exclude your documents from model training.
One exception, for completeness. Our MCP API works differently, because an MCP client is a program and cannot receive a file as a download: every file an MCP tool produces is written to a private storage bucket under your account id and answered with a signed link that stops working after an hour, with objects older than 24 hours removed automatically. That applies only to the MCP API, not to this website or the browser extension.
What Makes Us Different
Most PDF websites were designed when browsers could not do this work, so the file has to go to a server before anything happens to it. That was a reasonable decision at the time and it is now a habit. Browsers changed. Ours reads and writes the PDF locally for the tools that can be done locally, which is 18 of the 36.
The usual shape
Upload, queue, process, download. Your document sits on someone else's machine for the duration, and its safety there is a matter of their policy and their security record.
Ours, for those tools
The page loads the processing code, the PDF is read and written on your machine, and the result downloads from the tab. A file we never received is not in scope for a breach of our servers, because it was never on them. That is the whole of the claim, and the section above shows you how to check it.