Why Every Tool on This Site Runs in Your Browser — and How to Verify It

Published 2026-09-21 · by Tool Station · 100% private tools, no upload

"We never upload your file" is one of the easiest claims to write and one of the hardest to check. This is the long version: what local processing actually means in technical terms, what it costs, where its limits are — and a 60-second test you can run yourself instead of taking our word for it.

What "runs locally" means, precisely

When a tool runs locally, the bytes of your file never leave the device. Not "are deleted after processing on our servers" — never transmitted in the first place. The distinction matters: a service that uploads, converts and deletes after an hour can still be subpoenaed, breached or logged during that hour. A tool that never sends has no window to exploit.

Technically this is possible because modern browsers are a complete runtime. They can read a file from disk into memory, run compiled code against it (via WebAssembly) or plain JavaScript, and hand the result back as a download — all inside the sandbox, with no network call required.

The three steps every tool here performs

Despite the variety — PDF editing, background removal, DXF conversion, image packing — the shape is always the same.

1. Read. You pick a file, and the browser's File API hands the page a handle to it. The bytes go into an ArrayBuffer in the page's memory. Nothing has been transmitted; the operating system simply let the browser read a file you chose.
2. Compute. A library parses and transforms those in-memory bytes. For PDFs that is a JavaScript PDF library; for background removal it is a segmentation model running through WebAssembly; for DXF it is a parser reading the drawing's entity records. This is the slow part, and it happens entirely on your CPU.
3. Save. The result is wrapped in a Blob and offered as a download via an object URL. It writes to your disk from your browser. There is no server-side copy to fetch, because none was ever made.

The whole pipeline is three steps, and none of them includes the network.

Why not just do it on a server?

Because a server changes the threat model completely. The moment a file is uploaded, several things become true at once: the file exists on someone else's hardware; it likely touches a disk, a log line and possibly a backup; and your ability to prove what happened to it drops to zero. Server-side processing is also genuinely easier to build — bigger files, no browser quirks, one code path. We gave that up deliberately.

For most everyday jobs the trade is invisible: converting a recipe to PDF does not need privacy. It stops being invisible the moment the file is a contract, a medical image, an unreleased drawing, a customer list or a scan of someone's ID.

What you give up by going local

This is worth being blunt about, because a claim with no downsides is usually marketing.

• Memory is the hard ceiling. The file lives in browser memory. Desktop browsers handle large files comfortably; mobile browsers are much tighter, and a very large file on a phone can simply reload the tab.
• First load is heavier. The parsing libraries have to be downloaded before the first job. We serve them from this site rather than a third-party CDN so the page has no external dependency, but the initial download is real. After that, your browser caches them.
• Your device does the work. A background removal that would take two seconds on a data-centre GPU takes longer on a laptop. There is no queue and no rate limit, but there is also no free compute.
• No cross-device history. Since nothing is stored server-side, there is no "recent files" list when you switch machines. That absence is the feature.

How to verify it yourself in about 60 seconds

You should not have to trust this paragraph. Run the test:

The first test is the convincing one, and it is the only one that needs no technical knowledge: a tool that works with the network switched off did not use the network.

The limits of local-only

Local processing is a privacy property, not a cryptographic guarantee. It means no copy was transmitted. It does not:

• encrypt the file on your own disk — that is your operating system's job;
• protect you from malware or a keylogger already on the machine;
• stop someone looking over your shoulder or recording your screen;
• make a browser extension with page access harmless — extensions can read page memory, so keep the list short;
• remove hidden data inside the file. This one surprises people: our PDF editor's cover tool paints over content, but the underlying text remains in the file's content stream and can still be extracted. Running locally means no stranger got a copy; it does not mean the bytes were destroyed. That is a separate job, described in the redaction guide.

Saying this plainly matters. A privacy claim that overpromises is worse than no claim at all, because it changes what people are willing to share.

Frequently asked questions

Related guides