Browser-Based Tools and Your Privacy: How Local Processing Works
Every online tool asks you to hand over a file. Where that file goes afterwards is the difference between a convenience and a liability, and it is rarely stated plainly.
This guide explains the technical difference between local and server processing, how to check which one you are actually using, and where the honest limits of local processing lie.
What 'runs in your browser' means
Local processing means the code that transforms your file is downloaded to your device and executed by your browser's own engine. Your document is read from disk by the page, held in memory, transformed, and written back out as a download. No copy is transmitted.
Server processing means the file is uploaded, transformed on a remote machine, and downloaded back. That machine has the file, however briefly, and its retention, logging and backup behaviour is entirely a matter of trust.
Why local processing became practical
For most of the web's history, browsers were too slow for real document and media work. WebAssembly changed that by letting compiled code run at near-native speed inside the tab, and mature libraries for PDF manipulation, image codecs, archive handling and even video transcoding now ship in that form.
The trade-off moved rather than disappeared: instead of upload time you pay a one-time download of the processing engine, and instead of server CPU you use your own. For everything but the heaviest jobs, that is a clear win.
How to verify the claim yourself
Do not take a privacy badge at face value — measure it. Open developer tools with F12, select the Network tab, clear it, then run the operation on a reasonably large file.
If the file is being uploaded you will see an outbound request roughly the size of your document. If the only requests are for scripts and the operation completes, the work happened on your machine. You can go further and disconnect from the network entirely: a genuinely local tool will still work once its code has loaded.
What still needs a server
Honesty matters more than marketing here. Some work cannot reasonably happen in a tab: large-scale video transcoding where the file exceeds available memory, conversions that depend on a full office suite rendering engine, and anything requiring a licensed proprietary codec.
Anything involving a large language model also requires a server, because the model is far too large to download. When a tool is AI-powered, assume the text or image you submit is transmitted for inference, and do not paste secrets, credentials or regulated personal data into it.
Sensible habits
Match the tool to the sensitivity of the document. Use local tools for contracts, medical records, payslips, identity documents and anything under a confidentiality obligation. Reserve server-side or AI tools for material you would be comfortable seeing handled by a third party.
Redact before you convert rather than after. Once a document has been transmitted, removing information from your copy does nothing about theirs.
Frequently asked questions
- Do local tools work offline?
- Once the page and its processing engine have loaded, most local tools continue to work without a network connection, which is a useful way to prove that nothing is being uploaded.
- Why is the first run slower than later runs?
- The processing engine, often several megabytes of WebAssembly, is downloaded and compiled on first use and then cached by the browser for subsequent runs.
- Are AI features private?
- No AI feature that uses a large model runs locally. Assume the content you submit is sent to a model provider for inference and treat it accordingly.