How to tell whether an online tool uploads your file, in about 20 seconds

Every web tool says it is private. Almost none of them let you check. The good news is you do not need permission — you need the Network tab.

I paste customer data, private keys and production JSON into browser tools fairly often, so I stopped taking the claim on trust and started testing it. Here is the check, and what the results actually mean.

The 20-second version: go offline

1. Open the tool. Let the page finish loading.
2. Open DevTools (F12) → Network tab.
3. Set the throttling dropdown to Offline.
4. Use the tool.

A tool that runs locally keeps working. A tool that uploads breaks immediately, usually with a failed fetch or a spinner that never resolves.

This single test is the fastest lie detector I know, and it works because it tests the property you actually care about: whether your input can leave the machine at all.

The precise version: read the payload

Offline mode can produce false negatives — a tool might work offline for the demo but upload on "Convert". So for anything sensitive, do it the slow way:

1. DevTools → Network → filter to Fetch/XHR.
2. Press the clear button.
3. Now paste your input and run the tool.

Then look at what appeared.

Local processing produces a short list that has nothing to do with your input: the analytics beacon, maybe a font, maybe a config JSON. Request counts vary. What matters is payload size.

An upload shows up as a POST — commonly to a path named /upload, /convert, /api/v1/files or similar — with a request body roughly the size of what you pasted. Click it and check two things:

• Request headers: Content-Type: multipart/form-data; boundary=... for a file, or application/json with your text inside, is conclusive.
• Payload / Request tab: if your data is visible there, it left your browser. No privacy policy changes that.

One caveat worth knowing: WebAssembly and Web Workers do real work without making requests, so the absence of network traffic is strong evidence of local processing, while the presence of a few requests is not evidence of an upload. Judge by what is in the request, not by how many requests there are.

Three things that legitimately leave the tab

It helps to know what normal looks like, so you do not mistake it for a leak:

• Page weight. HTML, CSS, fonts, the analytics ping. None of it contains your input.
• Deliberate API calls. A tool that calls a translation service is uploading by another name, even if it calls it "processing". The Network tab tells you which one you are using.
• Browser-provided features. Text-to-speech via the Web Speech API uses voices installed on the operating system. That is local, and it looks different from a call to a cloud TTS endpoint.

Why "we do not store it" is a different promise

These are three separate claims and only the first one is checkable from your side:

Claim	What it means	Verifiable by you
"Nothing is uploaded"	Your input never leaves the device	Yes — Network tab
"We do not store it"	It arrived, but is deleted	Only by them
"We delete it after an hour"	It arrived and sat somewhere	Only by them

The first row is the only one where you can stop trusting and start testing. When someone offers you the third row, ask why they need the first hour.

Where this actually costs you

The failure is rarely dramatic. It looks like a small convenience: paste a .env to check a syntax error, drop a customer CSV into a converter, decode a token that happens to contain a live key. Files under a megabyte feel disposable, and that feeling is exactly what makes the habit stick.

The size of the file is not the thing. The thing is whether it left the machine.

Two examples of the check applied to tools you can try it on right now: a JSON formatter and a Base64 decoder. Both keep working with the network tab set to Offline, which is the only claim either of them makes.

Disclosure: I maintain itoolnet, the site linked above. The offline test in this post is what I use on my own pages before shipping them, and it has caught two regressions so far — which is the actual argument for running it on anyone's tool, including mine.