What “files never leave your browser” actually means

In 2024, security researchers found 89,062 documents sitting in an unsecured cloud storage bucket: passports, driver’s licenses, contracts, certificates. They all had one thing in common. Each one had been uploaded to a free online PDF tool by someone who just wanted to convert a file. The two sites involved looked exactly like every other converter on the internet.

Plume’s homepage makes a claim that sounds like marketing: your files never leave your browser. This post explains what that sentence literally means, why it is technically possible, and how to check it yourself, on this site or any other, without trusting a word I say.

Every online tool makes a choice

When a website processes a file for you, there are only two places the work can happen.

The upload model is how almost every well-known PDF site works, and it is a reasonable engineering choice: the serious players encrypt the transfer and publish deletion policies. But a copy of your document still existed on someone else’s machine, and from that moment its safety depends on their configuration, their employees and their mistakes. The 89,062 leaked files above were exactly this: temporary uploads in a bucket someone forgot to lock.

The local model sends nothing anywhere. The page you already downloaded contains the actual PDF engine, and it runs inside the browser tab, on your processor, in your memory. The “tool” is a small program the site hands to you, and your document never travels at all.

Upload tools ask you to trust how they store and delete a copy. Local tools remove the copy from the architecture entirely.

Promises versus properties

Upload-based sites usually answer privacy concerns with a retention policy: files are deleted after one hour, or a few hours, or 14 days for some features. Take those policies at face value and they are still a different kind of thing than local processing.

Promises depend on the company keeping them, forever, through acquisitions, outages, misconfigured backups and rushed deploys. Properties do not need keeping. This distinction, more than any single feature, is why I built Plume the way I did.

See it for yourself

Below is not a screenshot or an animation. It is Plume’s real compression engine, the same code that powers the Compress PDF tool, embedded in this post:

How to verify while it runs: open your browser’s developer tools (F12, or right click and choose Inspect), switch to the Network tab, and hand it a PDF, a big messy scan is ideal. With an upload tool, the very first thing you would see is your file leaving, because sending it is step one. Here, you may see the page fetch a bit more of its own code, since the demo loads lazily when you scroll to it. What you will not see is any request that carries your document: no upload, no POST with a payload the size of your file. You can even switch off your connection and the demo keeps working. The airplane-mode test is hard to argue with.

How a browser can rebuild a PDF without a server

The honest answer is that browsers quietly became a serious computing platform while nobody was watching.

Two things made the local model possible. First, JavaScript engines got fast enough to parse and rewrite real file formats. Second, and more importantly, browsers gained WebAssembly: a way to run compiled, near-native code inside a tab, in a sandbox, with no install. It is the same class of technology that lets Figma run a full design suite and Google Earth render a planet inside your browser.

Plume’s tools are built on that foundation. Reading and rendering PDFs, re-encoding the images inside them, recognizing text in scans, removing passwords: each of these runs as code your browser executes locally, much of it compiled to WebAssembly from the same engine families that desktop software uses. Your machine in 2026 is easily powerful enough. A mid-range phone can re-compress a 100-page scan in seconds. The upload model was never a technical necessity for most PDF work. It was just the default from an era when browsers could not do this.

The honest trade-offs

Local processing is not magic, and you should distrust anyone who sells it as such. Three things are genuinely different:

What does leave your device

Full honesty requires this section. Visiting any website transfers data, and this one is no exception:

The 30-second audit, for any PDF site

You do not need to be technical to hold tools to this standard. For any site that claims to be private:

One caveat, in fairness to everyone: this test proves what happened during your run, not what a site might do after its next deploy. That is why the test matters more than any badge. You can repeat it any time, on any site, in 30 seconds.

Why I built it this way

I build Plume solo, and I built it because I think the leaked-bucket story should be impossible by construction, not prevented by policy. A PDF is where your lease, your salary, your passport and your signature live. Tools that handle documents like that should not require trust as an ingredient, and the only way to remove trust from the recipe is to never receive the document at all.

If you want to see the architecture do real work, the compressor you just used is a lighter version of the full tool below. Same engine, same rule: it never sees your file, because there is no “it” anywhere but your own browser.