How We Keep Our Tools Private: The Architecture Behind Client-Side Processing

2026-09-14 · 7 min read · Privacy Engineering

We make a claim on every page of this site: that our tools process everything in your browser and never send your data anywhere. That claim deserves an honest explanation of how it is actually possible, because "no server" sounds either too good to be true or like a limitation. It is neither. This article walks through the architecture.

The capability you already own

For a long time, doing real work with a file meant sending it to a server, because the browser simply could not do the work itself. That changed over the last decade. The modern web platform now ships, natively, the very capabilities that used to require a backend:

The Canvas API can read, re-encode, resize, and draw on images — this is what powers image compression and conversion entirely on-device.
The Web Crypto API provides cryptographically strong hashing (SHA-256 and friends) and secure random generation, straight from the browser.
The File API lets a page read local files without uploading them, so you can process a document without it leaving your machine.

These are not exotic or experimental; they are standardized, shipped in every modern browser, and used by millions of sites. We just build tools that lean on them instead of on a server.

What "no server" means, precisely

It does not mean the page comes from nowhere — you still download the page itself from our server (or a CDN). What it means is that once the page is loaded, no more of your data goes anywhere. The initial download is one-way: code and page down, and nothing of yours up.

This has concrete consequences. There is no database that stores your text. There is no server that receives your image. There is no backend log that could record what you typed. The only network activity is the initial load, and you can verify that yourself with a browser's network inspector.

Why this is more honest than a privacy policy

A conventional tool asks you to trust its privacy policy: "we collect only X, we delete after Y, we never share Z." All of those are promises about a server you cannot see. A client-side tool removes the need for most of those promises, because there is no server in the loop to make promises about.

This is the key architectural difference, and it is why we think it is the right default for the kinds of files people process here. A tool that never receives your data cannot leak it, cannot sell it, and cannot be compelled to hand it over. That is not a stronger promise; it is a structurally different situation.

The honest limitations

We should be clear about what client-side does not do. It cannot help you collaborate with another person in real time, because there is no server to relay messages. It cannot persist your work to the cloud. And a handful of operations are genuinely too heavy for a browser, though fewer every year.

For the single-user, do-one-thing-and-close-the-tab use case that this site is built around, none of those limitations matter. For that use case, running locally is not a compromise — it is the whole point, and it is why a privacy tool is something you can build without a privacy policy full of caveats.