Browser file conversion and privacy: what really happens to your documents
Document conversion looks like a trivial chore until the document is a contract, a medical report or a draft under NDA. Then every click matters, and the question stops being whether the tool is fast and becomes where the file actually goes. Cloud converters and browser-based converters answer that question very differently — and the difference is verifiable, not something you must take on faith.
This article walks through the real data flow of cloud conversion, the threat model for sensitive files, how purely client-side conversion works under the hood, and — most importantly — how you can verify the claims yourself with nothing but your browser's developer tools. It closes with the honest limits of the local approach and what data minimisation means in practice.
What really happens to a file you upload
A typical cloud converter does more than its marketing page suggests. First the file is uploaded over TLS to the provider's servers. Processing then happens on machines you do not control, often on shared infrastructure. The output has to come back to you, which usually means at least one more server touch, and the working copies — original and converted — live somewhere in between.
That somewhere is governed by the provider's retention policy, which may delete files in minutes or keep them far longer, and by the jurisdiction of the data centre. Many services also rely on third parties for storage, queues, logging and analytics. Each hop is one more party that briefly holds your document, one more term you did not individually negotiate.
A threat model for sensitive documents
For a recipe collection none of this matters. For an unreleased contract, a patient record, a litigation file or a manuscript under NDA, the calculus changes. The threat is rarely a malicious operator reading your PDF; it is the accumulation of copies — on disks, in backups, in logs — that you cannot enumerate, cannot delete on demand and cannot audit.
Sensitive material also has a longer tail than you expect. A document that is harmless today can become commercially or legally delicate two years from now, and retention policies are written by the party holding the data, not the party that created it. The only retention policy you fully control is the one where the file never leaves your device.
How client-side conversion works
Browser-based conversion inverts the flow: the engine travels to the file, not the other way around. The site loads a conversion engine — in this case real Pandoc compiled to WebAssembly — into your browser. WebAssembly runs in the same security sandbox as ordinary JavaScript: no access to your filesystem, no network authority of its own, and no way to phone home unless the page explicitly opens a connection.
The conversion itself runs inside a Web Worker, a background thread separate from the page UI. Your document is handed to the worker as bytes in memory, parsed, transformed and returned; nothing is written to disk beyond the download you trigger, and no server round trip is needed to finish. When the conversion ends, those bytes are garbage collected like any other variable.
Verify it yourself
The claims are testable in about two minutes. Open your browser's developer tools, switch to the Network panel, load a converter page and drop in a file. During a client-side conversion the panel stays empty — no POST, no upload progress, no mysterious request to an API endpoint. Everything you see is whatever the page itself loaded as assets.
Two stronger checks follow. First, once the engine has been fetched and cached, load the site, go offline via DevTools or by disconnecting, and convert again — it still works, which is only possible if nothing needs the network. Second, browse the Application tab: Cache Storage shows the cached engine, and you can confirm no queue of pending uploads exists anywhere. Run this test on any tool that claims to be local; trust the panel, not the promise.
The honest limits
Local conversion is not magic, and overstating it helps nobody. The engine itself — tens of megabytes for Pandoc — has to be downloaded once, and that first fetch reveals your IP address and user agent to the host serving it, as every web request does. It also depends on TLS and on the integrity of the code that gets delivered.
Other limits are environmental. Browser extensions can read page content, so a hostile extension undermines any privacy claim; compromised machines compromise everything; and a page could in principle change its behaviour after you trusted it once. The sane posture is to verify per site, keep extensions minimal for sensitive work, and re-check after major updates.
What this site stores locally
On this site the stored state is deliberately small. The Pandoc WebAssembly engine is cached in Cache Storage so conversions work offline after the first use, and the interface keeps a preference such as your theme choice in local storage. That is the entire inventory.
Your documents exist only in memory while a conversion runs, and output reaches your disk solely because you clicked download. There is no account to delete, no server-side copy to request removal of, and no analytics trail of what you converted. Closing the tab leaves nothing behind but the cached engine and your theme.
Why regulators like data minimisation
Data protection law has a principle that maps neatly onto this architecture. GDPR's data minimisation requires that personal data be limited to what is necessary — and a converter that never receives the document satisfies that almost by construction. If no file crosses the wire, there is no processor to vet, no data processing agreement to sign and no cross-border transfer to assess for the conversion step itself.
This is not legal advice, and it does not make every workflow compliant — the content still has to be handled lawfully wherever it is stored. But moving transformation to the client removes an entire category of third-party exposure from the risk assessment, which is why privacy-conscious teams, hospitals and law firms increasingly insist on tools that keep files on the device.