Why browser-based tools are private by architecture, not by promise

A privacy policy is a promise; an architecture is a fact. This article explains the technical difference between tools that upload your files to a server and tools that process everything in your browser — and how to verify, yourself, in under a minute, which kind you are using.

Most online tools ask for trust in the most literal way: you upload a document, an image, sometimes a password-adjacent secret, their server processes it, and a privacy policy assures you it is deleted afterwards. That assurance may be entirely honest — and it is still only an assurance, covering today's operator, today's configuration, today's log settings. Browser-based tools make a categorically different claim: the file never leaves your device, because the processing happens in the page, in JavaScript, on your machine. That claim has the rare virtue of being checkable by the person it protects.

This article explains the architecture, the specific browser capabilities that make it possible, and the one-minute verification anyone can run. It also marks the honest boundaries: what client-side processing does not protect, and where a server is genuinely necessary.

Two architectures, two kinds of trust

In the server model, your data crosses the internet, is processed on someone else's computer, and the result returns. Every hop is a custodian: transit logs, application logs, backups, error trackers, the operator's future acquirers. Policies govern all of them, and breaches of processing servers are a staple of the news precisely because valuable data accumulates there. None of this makes server tools illegitimate — collaboration, heavy computation and cross-device sync genuinely need servers — but for single-device utilities, the exposure is bought with your data and pays for nothing you need.

In the browser model, the web page is the program and your device is the computer. The server that delivered the HTML and JavaScript is out of the loop the moment the page loads — provably so, because you can cut the network and keep working. This is the model this site uses for everything: password generation draws on your OS's entropy via Web Crypto; image tools draw your photo onto a local canvas; converters parse your text in the page. The trust question shrinks to one about the code itself — and code delivered to your browser is, uniquely, code you can inspect.

The capabilities that make it possible

• File API: a page can read files you select or drop, as local data — reading is not uploading, and the distinction is the whole ballgame.
• Canvas API: images can be decoded, resized, re-encoded (JPEG/PNG/WebP) and offered back as downloads, entirely client-side.
• Web Crypto (SubtleCrypto): SHA-family hashing, secure random generation and more, implemented natively and fast — no server, no library risk for the primitives.
• Ordinary computation: parsers, diff algorithms, encoders and formatters are just JavaScript; text you paste exists in the page's memory and nowhere else unless the code sends it somewhere.
• Local storage: preferences like a theme can persist on your device without an account or a database — and should be limited to exactly that class of data.

Verify it yourself in one minute

1. Open your browser's developer tools (F12 or right-click → Inspect) and select the Network tab. Reload the tool's page and let it settle.
2. Clear the log, then use the tool with real-shaped input: generate a password, drop an image, paste a document.
3. Read the log. Loading the page fetched HTML/CSS/JS — that is delivery. Using the tool should add no requests at all, and certainly none carrying your input as a payload.
4. The aeroplane-mode test: disconnect the network entirely and use the tool again. If it still works end to end, uploading is not merely promised-against; it is impossible in that session.
5. Check what persists: in the Application/Storage panel, see what the site stores. A theme preference is proportionate; your document text would not be, and on this site you will find it absent.

Run that once and you never again have to take any tool's privacy page — including ours — purely on faith. That transfer of verification power to the user is the architecture's real feature.

The honest boundaries

Client-side processing is not a halo. The JavaScript a site serves could be malicious or compromised, and it changes whenever the site changes — inspection proves a moment, not a future. Third-party inclusions (advertising, analytics, embedded widgets) are separate code with separate data flows, and a page can be private in its tools while being chatty in its trackers; the network tab will show you both, which is another reason to look. Some jobs are also simply beyond the browser: files beyond device memory, computations needing server-class hardware, anything collaborative or synced. The claim worth trusting is never 'we are private' in the abstract — it is the specific, testable one: this tool, this input, no transfer, check for yourself.

Mistakes and pitfalls

Equating 'has a privacy policy' with 'is private'

A policy describes intentions and obligations; it cannot reduce the technical exposure of an upload architecture. Read policies, by all means — after the architecture, as the second layer of judgement, not the first.

Assuming HTTPS settles the question

HTTPS protects data in transit — from eavesdroppers between you and the server. It says nothing about what the server at the end does with your file. Encryption of the pipe is not privacy from the recipient.

Believing 'we delete after processing' is verifiable

It is not, from outside — which is precisely the asymmetry this article is about. Deletion promises may be kept faithfully and still cannot be checked; absence of transfer can be. Prefer, where the job allows, the claim you can test.

Common questions

If nothing is uploaded, why does the site need hosting at all?

To deliver the program — the HTML, CSS and JavaScript — the way an app store delivers an app. After delivery, the computation is local. The host sees page requests, as every website does; it never sees the contents you process.

Can a browser tool work fully offline?

Once loaded, yes for tools like these — and a saved page often keeps working from disk. Formal offline support (service workers, installability) is a product choice on top of the same architecture; the privacy property does not depend on it.

Are desktop apps automatically more private than web tools?

No — desktop software can phone home as freely as any server tool, and it is harder for a typical user to watch its traffic. The question is always the data flow, not the form factor; the browser's gift is that its flows are unusually easy to inspect.

To wrap up

Privacy that rests on promises scales with the promiser's virtue and lifespan. Privacy that rests on architecture — your data processed on your device, verifiable in your own network tab — scales with the laws of arithmetic instead. For the small, single-purpose jobs tools like these do, insist on the second kind, and spend your trust where only trust will do.