🌙 Dark

What “runs in your browser” actually means

A claim you do not have to take on trust — and how to check it in about thirty seconds.

Last updated 2 September 2026 · ToolsAre.Us Guides

Plenty of web tools advertise that your files "never leave your device". It is a meaningful claim with a precise technical meaning, and unusually for privacy promises, it is one you can verify yourself in under a minute without any specialist knowledge. This guide explains what the claim means, how to check it, and — importantly — what it does not cover.

Two ways a web tool can work

Server-side. You choose a file. The browser uploads it. A machine somewhere processes it and sends a result back, which you download. Your file existed, however briefly, on hardware belonging to someone else. It may have been written to disk, backed up, logged, or retained by policy. You are trusting the operator's promises, because from your side the process is opaque.

Client-side. The page arrives as HTML, CSS and JavaScript. When you choose a file, the browser hands the page a reference to it and the JavaScript does the work using facilities the browser already provides — canvas for images, Web Audio for sound, WebAssembly for heavier tasks. Nothing is transmitted. The result is generated in memory on your machine and offered back to you as a download.

The distinction is not a matter of degree. Either bytes went over the network or they did not.

How to check, in thirty seconds

Every major desktop browser ships the tool for this. No plugins needed.

1. Open the tool's page and let it finish loading.
2. Press F12 (or Ctrl+Shift+I; on a Mac, Cmd+Option+I) to open developer tools.
3. Select the Network tab.
4. Click the clear button so the list is empty. This discards the page's own loading traffic, which you do not care about.
5. Now use the tool — drop in your file, run the conversion, whatever it does.
6. Watch the list.

If processing is genuinely local, you will see nothing at all, or only small unrelated requests such as an analytics ping or an advert. If your file is being uploaded, you will see a POST or PUT request whose size roughly matches your file. A ten-megabyte upload is unmistakable: sort by size and it will be at the top.

This is the useful property of the claim — it is falsifiable. A site can say anything in its privacy policy, but it cannot hide a ten-megabyte upload from the Network tab.

A subtlety worth knowing: some tools are local for processing but contact a server for one specific feature, such as creating a share link. That is legitimate and often necessary — a link others can open must point at data someone else can reach. What matters is whether the page tells you which actions involve a server. "Everything is local" alongside a working share link is a contradiction, and the honest version names the exception.

What still leaves your device

Client-side processing protects your file contents. It does not make you invisible, and it is worth being precise about what still happens.

• The page itself. You requested it, so the server knows your IP address, roughly when you visited, your user agent, and often the referring page.
• DNS lookups. Before connecting, your device asks a resolver for the site's address. Unless you use encrypted DNS, that query is visible to your network and your ISP.
• TLS handshake metadata. HTTPS encrypts the content but the hostname is typically visible during connection setup, so observers can see which site you visited, though not what you did there.
• Analytics. Most sites record page views. That is about visits, not file contents, but it is still a network request.
• Advertising. Ad networks receive a request including your IP and the page URL, and generally set cookies. This is usually the largest third-party exposure on an otherwise-local page.
• Third-party assets. Fonts, icons or libraries loaded from a CDN mean a request to that CDN on every page load.

So the accurate statement is narrower than "nobody knows anything": the contents of your file were never transmitted. That is a genuine and substantial protection, and it is not the same as anonymity.

Where local data actually goes

A tool that remembers your work between visits is storing it on your machine, and the mechanism matters.

• localStorage — a simple key-value store, a few megabytes, persists until cleared. Good for preferences and small documents.
• sessionStorage — identical but discarded when the tab closes.
• IndexedDB — a real database supporting large binary data. What a tool would use to keep files or images between sessions.
• Cookies — the only one of these that is sent to the server automatically with every request. The others never leave the browser unless page code explicitly transmits them.

All of these are partitioned by origin — the combination of scheme, hostname and port. Data stored by one site is unreadable by another; that isolation is enforced by the browser, not by site cooperation. It also means storage is per-device and per-browser. Work saved in Chrome on a laptop is not available in Firefox on the same laptop, let alone on a phone. Clearing site data, or using a private window, removes it.

The limits of doing everything locally

Local processing is not free of trade-offs, and a few are worth understanding:

• Your device does the work. A large job runs at the speed of the machine in front of you. A phone will be slower than a desktop, and a very large file may exhaust available memory in a way a server would not.
• Everything must be downloaded first. A tool needing a large library ships that library to you before it can start.
• Sharing genuinely requires a server. A link someone else can open has to reference data stored somewhere reachable. There is no way around this, and any tool offering share links is storing something.
• Collaboration requires a server for the same reason.
• Browser capabilities set the ceiling. Some formats and codecs simply are not available in a browser, which is why certain conversions remain server-only.

Judging a claim honestly

Signals that a privacy claim is being made in good faith:

• It says specifically what stays local, rather than gesturing at "we respect your privacy".
• It names the exceptions — share links, analytics, adverts — instead of leaving them for you to discover.
• The tool keeps working with the network disconnected, which is the strongest possible demonstration.
• The privacy policy distinguishes what the site collects from what the tool processes. Those are different questions and a careful policy answers both.

And the simplest test of all: turn off your network connection, reload nothing, and use the tool. If it completes the job offline, the processing was unambiguously local. No policy document is as convincing as that.