Search for “merge PDF” and every result on the first page works the same way. You choose a file, it uploads, a server somewhere does the work, and a download link comes back. The upload is so normal that most people never think about it.
It is worth thinking about, because it is not a technical requirement. Browsers have been able to read files, process them, and write results for years. The upload exists for a different reason.
The real reason is cost recovery
Server-side processing costs money on every single use — bandwidth in, compute, bandwidth out. A site doing a million merges a month is paying for a million round trips. That cost has to come from somewhere, and it comes from the things you notice: the advertising wrapped around the tool, the file size cap that pushes you toward a subscription, the queue at busy times, the account you are asked to create.
It also creates an asset. Files arriving on a server are data, and data has value — for analytics, for training, or simply as a reason to ask for your email address before you can download the result.
What changes when the work happens locally
Doing the same job in your browser removes the cost, and with it the reasons for most of what makes those sites unpleasant.
It is faster. A 40 MB PDF does not need to travel to a data centre and back. On a typical connection the upload alone takes longer than the entire local operation. The gap widens as files get larger, which is exactly when you care most.
The privacy claim becomes checkable. “We delete your files after an hour” is a statement about someone’s internal processes that you have no way to verify. “Your file never leaves your device” is a claim about network traffic, and you can confirm it yourself: open your browser’s developer tools, watch the network tab, and process a file. Nothing goes out. We also serve our tool pages with a Content Security Policy that blocks the page from sending your file anywhere, so the guarantee holds even if our own code were changed.
It works offline. Once a page has loaded, it keeps working with no connection at all.
Where this approach genuinely does not work
Being straight about the limits matters more than the pitch.
Your device does the work, so its memory is the ceiling. A phone will fail on a file a laptop handles comfortably. Where a limit exists we state it on the tool’s own page rather than letting it fail mysteriously.
Some formats have no native browser support. HEIC photos from an iPhone are the common example — no browser decodes them, which is why almost every HEIC converter online uploads your photo to a server that can. Where a format matters enough, the answer is to ship the decoder instead: our HEIC converter carries a WebAssembly build of libheif, so the photo still never leaves your machine. It costs about 1.5 MB of download, which is a fair trade.
And some work is genuinely too heavy for a laptop. Large model inference is the obvious case. Where that is true, the honest answer is a server plus your explicit consent, on a page that says so before you upload anything — not a quiet exception to a promise made elsewhere.
The short version
Anything that can run on your device should. Not because local processing is philosophically purer, but because it is faster, it makes the privacy claim verifiable rather than aspirational, and it removes the cost that pushes other sites toward advertising and upsells.