"We are safe" is an unfalsifiable claim. Use the offline test, the DevTools Network panel and resource-loading shape to verify for yourself whether any online tool uploads your files — plus how in-browser processing actually works, what it costs, and when cloud is the right call.
Every day, an enormous number of contracts, scanned IDs, bank statements and medical reports get dragged into whatever "free online PDF merge" site came up first in search results.
Most people never think about where the file went. And every one of those sites will tell you it's safe — which is an unfalsifiable claim. There is no way to judge a statement like that from the statement itself.
The good news: you don't have to take anyone's word for it. Whether an online tool uploads your file is something you can verify yourself — three methods, no special software, a few minutes to a firm answer.
This post is about the method, not the conclusion. Use it on any online tool you like — including this one.
The logic is simple: if a file has to reach a server to be processed, the feature cannot finish once you're offline.
Steps:
How to read it:
| What you see | Conclusion |
|---|---|
| The flow completes and you download a correct output file | Processing is local |
| It hangs on "processing", spins forever, or throws a network error | A server is involved |
Two traps to avoid, or you'll misread the result:
Trap 1: load the page first, then disconnect. Reverse that order and it fails trivially — the page itself can't download, which tells you nothing about where the processing happens.
Trap 2: the page opening offline ≠ processing happening locally. Plenty of sites use a Service Worker for offline caching, so the page loads fine while clicking "process" immediately errors out. You must run the full flow through to a downloaded result file; whether the page opens proves nothing on its own.
What makes this convincing is that it routes around all marketing language. If a 100-page PDF merges and downloads with the network fully severed, that can only have happened on your own device.
The offline test gives you a yes/no. The Network panel tells you exactly what left and how big it was.
Steps:
F12, open NetworkKey things to get right:
POST. Some services fetch a pre-signed URL from their backend and then PUT the file straight into object storage like S3 or R2. What matters is the request body size, not the HTTP verb.multipart/form-data wrapping your filename, it was uploaded.Fetch/XHR cuts out most of the static-asset noise.To be fair about this: requests of a few KB are completely normal — analytics, error reporting, fonts and telemetry all look like that, and they are not your file leaving. The signal is an outgoing request whose size matches your file, not "there were network requests at all." Every page makes network requests.
This is an inverted signal, and a surprisingly reliable one: local and cloud processing have completely different resource-loading shapes.
Look at the incoming resources in the Network panel:
What a local implementation looks like — it pulls down some conspicuously large things:
.wasm files (WebAssembly modules, hundreds of KB to several MB)What a cloud implementation looks like — a light frontend:
So a simple mental model:
It downloaded tens of MB and sent nothing out → local. It downloaded a few hundred KB and sent out 8MB → cloud.
This also explains something people often misread: why a local AI tool is so slow the first time. It's downloading an entire model into your browser. That slowness is the price of not uploading — and the evidence of it.
This post couldn't have been written five years ago — back then most of this genuinely had to live on a server. What changed is a handful of browser capabilities maturing:
| Capability | What it made possible |
|---|---|
| WebAssembly | Image, crypto and model-inference libraries written in C/C++/Rust running in the browser at near-native speed |
| Web Crypto API | crypto.subtle provides AES-GCM, SHA-256, HMAC and RSA natively, hardware-accelerated, with no hand-rolled cryptography |
| Canvas / OffscreenCanvas | Pixel-level image work, format encoding (JPEG/WebP/PNG) and downsampling — runnable in a Worker so the UI stays responsive |
| File API / Blob | Read local files, build new ones in memory, trigger a download — never touching a server |
| Device performance | An ordinary laptop now has the RAM and CPU to reassemble a few-hundred-page PDF in memory |
Concretely, here's what these tools are actually doing in the browser:
pdf-lib parse and rewrite the PDF byte structure directly (object streams, cross-reference tables), assembling a new file in memorypdf.js renders pages onto a Canvas, which is then exported as PNGNone of this is a trick to "move the server into the frontend." These capabilities simply live in the browser now.
If this post only listed upsides it would become exactly the kind of marketing copy it opened by criticizing. Local processing involves real trade-offs:
1. The first load can be heavy. Anything model-backed (AI background removal, say) downloads tens of MB on first use. The browser caches it afterwards, but that first run is genuinely worse than cloud.
2. You're bounded by device memory. A server has tens of GB of RAM; your browser tab does not. A few-hundred-MB PDF, or a batch of several hundred images at once, can take the tab down — where a cloud service would swallow it easily.
3. Some things genuinely can't be done locally. High-quality OCR, large-model inference that needs a GPU cluster, cross-device sync, processing history, shareable team links — those depend on a backend. It isn't for lack of trying.
4. Phones are noticeably slower. Mobile CPU and memory are both tighter; the same operation can take several times longer than on desktop.
5. Close the tab and it's gone. There's no server-side job queue, so you can't submit and walk away.
Reach for cloud when:
Don't reach for cloud when — once this content leaves your device, you've lost control of it:
For that category of file, spending three extra minutes on the offline test is entirely worth it.
Every tool here runs locally in your browser and uploads nothing. You shouldn't take that on faith — run the three methods above and find out, especially the offline test.
The ones people most often use on sensitive files:
One last note: encryption tools in particular have no business being server-side. Sending your plaintext and your password to someone else's machine defeats the entire point of encrypting it.