How to tell whether a PDF tool uploads your file

Almost every free PDF site asks you to choose a file and then shows a progress bar. Some of them are copying that file to a server on the other side of the world, and some of them are not touching it at all. The difference is invisible from the outside, and it is not hard to check.

Last reviewed October 2026. If a page like this is ever rewritten, the date moves with it.

The two ways a PDF tool can possibly work

To change a file, something has to read it. Either that something is your own device, or it is a machine belonging to whoever runs the site — and if it is their machine, the file has to get there first. There is no third option. So the question is never "does this tool upload?" in the abstract; it is "where does the work happen?"

For a long time the answer had to be a server. Browsers in 2010 could not parse a PDF, let alone rewrite one. That stopped being true: a browser can now run the same kind of code a desktop program runs, at close to the same speed, using the standards that let heavy applications work without an install. Merging, splitting, rotating, compressing and even reading text out of a scan are all things a single browser tab can do on its own.

Both kinds of tool exist today, and the second kind is not automatically better. It is simply a different trade: nothing to leak, nothing to delete afterwards, no waiting for a slow connection — in exchange for the work being limited by whatever device you happen to be holding.

The two-minute test anyone can run

Open the tool, and before you give it anything, open your browser's developer tools (F12, or right-click and choose Inspect) and switch to the Network tab. Now process a file. If the site is uploading, you will see a request carrying your document — usually a POST with an obviously large payload, sometimes a live socket staying open while the progress bar moves. If the only things in that list are scripts, stylesheets and images, the file never left.

The simpler version, which needs no tools at all: load the page, then turn off Wi-Fi or unplug the network cable, and try to process a file. A tool that worked on a server cannot possibly work now. A tool that does the work locally will carry on as if nothing happened — which is exactly the point.

Two other habits are worth having. Look for the words an honest tool uses about itself: a retention period, a deletion promise, a named third party. A site that processes on a server should say how long it keeps the file, and a site that does not should be able to say so plainly. And glance at the list of scripts the page loads: a file can also be handed away by a third-party script that runs alongside the tool, no matter how the tool itself works.

What "no upload" does not promise

It does not mean the site is trustworthy in every other respect. A page that never sees your file can still be dishonest about what it does with your attention, or about what its download button actually delivers. Privacy and honesty are two separate qualities, and it is worth judging them separately.

It does not mean unlimited capacity. Work done on your device is limited by your device: a 400-page colour scan that a server farm would chew through in seconds may stall on a mid-range phone, and memory is the usual reason. Splitting the job, or using a desktop, is often the practical answer.

It does not mean the output is better. Quality comes from the library doing the work, not from where it runs. A careless server tool and a careless browser tool will produce the same careless result.

And it does not mean the site owner learns nothing. The page still has to be downloaded from somewhere, so the visit itself is visible to the host in the ordinary way — just not the document.

When uploading is honestly the right choice

There is no prize for refusing to upload. If the file is something you would happily email to a colleague, sending it to a well-run service changes very little. If a form demands a PDF in a format only one tool produces, use that tool.

The rule worth keeping is narrower and more useful: match the tool to the document. A passport scan, a medical report, a signed contract, a client's accounts — anything where a copy on someone else's disk is a real risk — belongs in a tool that never receives it. A restaurant menu you are reformatting does not.

Practically, most people do not need to think about this at all most of the time, and do need to think about it occasionally. Knowing that the two kinds of tool exist, and how to tell them apart in two minutes, is enough to make the second kind of decision well.

What this site does, exactly

Every tool here works the first way. Your file is read by your own browser, changed in memory on your own device, and handed back to you as a download. It is never transmitted to us — not to be processed, not to be stored, and not to be checked afterwards, because there is no copy anywhere to check.

That has three visible consequences. Nothing is uploaded, so a large file is not limited by your connection. There is no account, no queue and no daily limit. And after the page has loaded once, the tools keep working when the network does not.

The only thing this site stores on your device is the choice between the light and dark theme, kept as a single word in local storage. There are no cookies and no tracking pixels; the privacy page sets out the same position in more detail.

You do not have to take any of that on trust. Run the test above on any tool here — pull the network cable out and watch it keep working.

Questions

Does "no upload" mean the tool works offline?

For most tools here, yes — after the page has loaded once, the work happens on your device and needs nothing from the network. Text recognition is the exception in practice: the first run downloads the language data it needs, and then that too is cached.

How can a browser do this at all?

The same standards that let a heavy application run without an install let a browser run one too. The file is parsed and rewritten in memory, on your own processor, rather than being shipped somewhere faster.

Is a browser tool slower than a server one?

It depends on the device rather than the approach. A server can throw a bigger machine at a job, so very large scans can be quicker there. On ordinary documents the difference is usually not noticeable, and not having to upload or download the file often makes up for it.

If a tool does upload, what should I look for?

A stated retention period, a clear deletion promise, and a named third party if one is involved. A site that processes files on a server and does not say what happens to them afterwards has told you the most important thing about itself.

Is a local tool automatically safer?

No. It is safer in one specific way — your document stays with you — and that is a meaningful kind of safer for contracts, identity documents and client files. Everything else about a site still deserves the usual scepticism.

All tools