The default web is “upload by default.”
Every file tool on the open web works the same way. You drop a PDF, it gets sent to a server, the server does the work, and you download the result. There is no security model for what happens on that server. There is no audit trail. There is only a “we delete after one hour” promise on a TOS page.
What “in your browser” actually means
This page bundles the file-processing engines as JavaScript and WebAssembly. When you drop a PDF on the merge tool, the merge happens inside the same tab that’s displaying this text. The merged PDF is held in memory and offered as a download. There is no HTTP request carrying your file because there is no upload step in the code.
How you can verify it
- Open DevTools, then the Network tab.
- Drop your largest PDF on any tool.
- Click Process or Download.
- Watch the network log. You will see zero outbound bytes for your file.
The only network activity is library code on first use (pdf-lib, ffmpeg.wasm, and so on) and an anonymous usage count that never includes file names or contents. Once a tool’s code is cached, you can turn off Wi-Fi and it keeps working. The site’s security policy makes the browser block requests to any server not on its short list, so even a compromised library couldn’t send your file away.
What this costs us
Some operations cannot run in a browser at acceptable fidelity. PDF → Word needs LibreOffice. Validated PDF/A conformance needs a real validator. Very large video transcodes are slow without a server. We picked the side of the trade-off where these features don’t exist, rather than the side where “private” comes with quiet asterisks.
If you have to trust a promise on a TOS page, it isn’t privacy. It’s deferral.
The wedge
Every other file tool is built on a server-side architecture that requires uploads. We rebuilt the same operations using WebAssembly and native browser APIs that didn’t exist when the incumbents were designed. The tooling matured; we got to skip the cloud.