Why your files should not have to leave your browser

A lot of online tools work the same way: you pick a file, the page uploads it, the server processes it, and a result comes back. It is fast and it is convenient. But it is also a specific privacy decision — and most people make it without noticing. This article explains what that decision actually is, and why “runs in your browser” is a meaningfully different model.

What “upload” really means

When a tool uploads your file, several things happen that are easy to underestimate.

1. Your file is now on someone else’s infrastructure. It is stored, at least briefly, on a server you do not operate, under a policy you did not write.
2. It may be retained longer than the job. Uploads are often logged, cached, or kept for debugging. “We delete it after processing” is a promise, not a mechanism you can verify.
3. It becomes a record of you. A file is not just bytes; it is evidence. A contract, a letter, a photo, a spreadsheet — each says something about you that you did not choose to share.
4. The network is a surface. In transit, a file crosses infrastructure that can be logged or intercepted, independent of what the destination does.

None of this is necessarily malicious. Most services are honest. The point is that the default of upload-based processing is that your private file is handled outside your control, and the burden is on you to trust that it is not.

What “runs in your browser” means

A local tool does the opposite. The processing engine — in DailyWise’s case, a WebAssembly module — runs on your device. Your file is read, transformed, and written back, all on your machine. The consequences are structural, not promises:

• No upload, so nothing to retain. There is no server copy because the file never left.
• No network dependency for the core job. The same conversion works offline, because no remote service was ever in the loop.
• No third party ever sees the file. Not the host, not a CDN, not a logging layer — because there is no hop.
• The file’s privacy is a property of the architecture, not a line in a policy. It cannot be leaked on a server that never received it.

This is the key difference: an upload-based service’s privacy is a claim you have to trust; a local tool’s privacy is a consequence of where the code runs.

How to tell them apart

You can usually tell without reading a single privacy policy:

• Does it work offline? Open the tool with the network cut. If the core function still works, it is running locally. If it fails, the file is going somewhere.
• Is there a file size or quota limit framed as “upload”? Limits phrased around uploads are a sign the file leaves your device.
• Does it ask for an account before doing the obvious thing? An account wall before a simple conversion is a signal that the file (or you) is being captured.

What this does not mean

Local processing is not a universal good, and it is worth being honest about its limits.

• Heavy jobs have a cost. A very large video or a complex conversion uses your device’s memory and CPU, and can be slow or fail where a big server would handle it easily.
• Some tasks genuinely need a service. OCR of a difficult scan, or a format that needs a full backend, may not run well in a browser.
• “Local” is about the file, not the site. A local tool can still show you ads and set the usual analytics cookies. The file stays private; the site’s other practices still deserve the normal scrutiny.

The honest bottom line

You should not have to hand a private file to a stranger’s server to get a simple, mechanical job done. When the work can run on your device — and conversion, compression, and formatting usually can — running it there is not a feature; it is the default a tool should have. The question to ask of any online tool is simple: where does my file go, and why do I have to trust it?