Search for a PDF merger and you will find dozens of free websites. Almost all of them work the same way: you upload your file, their server processes it, and you download the result. It is a perfectly reasonable architecture for public documents and a genuinely poor one for the contracts, statements and identity documents people actually merge.
What 'upload' actually means
When a website processes your file server-side, a complete copy of that file travels across the internet and is written to a machine you do not control. It sits there while it is processed, and typically for some period afterwards — most services delete files after an hour or a day, though you have only their word for it.
During that window, the file exists in their infrastructure, their backups, and potentially their logs. It is accessible to their staff, to anyone who compromises their systems, and to any legal process directed at them. None of this requires bad intent on the operator's part; it is simply what server-side processing means.
For a holiday photo this is irrelevant. For a signed contract, a bank statement, a medical form or a passport scan, you have created a copy of a sensitive document in a location with unknown security properties and an unknown retention policy.
What browsers can do now
The reason upload-based tools dominate is largely historical. A decade ago, browsers genuinely could not manipulate a PDF or resize an image efficiently, so server-side processing was the only option. That has not been true for years.
Modern browsers ship with a capable canvas engine for image manipulation, the Web Crypto API for hashing and random number generation, File and Blob APIs for reading and writing local files, and enough JavaScript performance to run libraries that read and write PDF structures directly. WebAssembly extends this further, allowing genuinely heavy processing — video transcoding, image format conversion, compression — to run at close to native speed inside a tab.
The practical consequence is that the large majority of file-processing tasks people use websites for can now be done locally. Merging PDFs, resizing images, formatting JSON, decoding tokens, generating QR codes, hashing text — none of these need a server, and every one of them is faster without one.
- Canvas handles image resizing, compression and format conversion.
- Web Crypto provides hashing and cryptographically secure randomness.
- File and Blob APIs read and write local files without an upload.
- WebAssembly brings near-native performance for heavier work.
Local processing is also just faster
Privacy is the headline benefit, but speed is the one you notice. A 20 MB PDF takes real time to upload on a typical home connection, then waits in a processing queue, then downloads again. Locally, the same operation completes in a second or two with no network involved at all.
There is also no file size ceiling. Upload-based services impose limits — usually somewhere between 10 and 100 MB on free tiers — because bandwidth and storage cost them money. A local tool is limited only by your device's memory, which on any modern machine is considerably more generous.
And it works offline. Once the page has loaded, a genuinely local tool keeps functioning without a connection, which is occasionally very useful and always a good sign that the processing really is happening where the site claims.
How to verify a tool's claims
Any website can claim it processes files locally. Fortunately, this is one of the few privacy claims you can check yourself in under a minute, with tools already built into your browser.
Open the developer tools, switch to the Network tab, and use the tool as normal. If your file is being uploaded, you will see a request carrying it — the size alone gives it away. If processing is genuinely local, you will see nothing beyond the page's own assets.
The stronger test is to disconnect from the internet entirely after the page has loaded. A local tool carries on working; an upload-based one fails immediately. This takes ten seconds and settles the question definitively.
- Watch the Network tab while using the tool — an upload is impossible to hide.
- Disconnect from the internet after loading and try again.
- Be sceptical of any tool that requires an account to process a file locally.
When a server is genuinely necessary
It would be dishonest to claim everything can run locally. Optical character recognition, high-quality video transcoding, large language model inference and anything requiring a proprietary dataset all still benefit from or require server infrastructure.
The point is not that servers are bad. It is that a great many tools use them for tasks that do not need them, and that the resulting privacy cost is invisible to most users at the moment they upload.
When a server genuinely is required, a trustworthy service says so plainly, explains what it retains and for how long, and does not bury it in a privacy policy nobody reads. Ambiguity on this point is itself informative.
Key takeaways
- Uploading a file creates a copy on infrastructure you do not control.
- Modern browsers handle most file processing locally without any server.
- Local processing is faster, has no size limit, and works offline.
- You can verify the claim yourself using the browser's Network tab.