How to check whether a web tool really keeps your file

“Your files never leave your device” is a sentence, and sentences are free. Any site can print it, including sites that upload everything.

The good news is that this particular claim is unusually easy to verify. You are not auditing source code — you are checking whether data crossed a network, and your own browser will tell you.

The short version

Four tests, easiest first:

1. The offline test. Load the page, disconnect, use the tool. If it works, the work is happening locally. Thirty seconds, no expertise.
2. The network panel. Watch for outbound requests the size of your file. Two minutes, and it is conclusive.
3. The size test. Compare what moved against what your file weighs. Built into test 2.
4. The instant test. Judge how long it took against your connection speed. A hint, not a proof.

Test 1: pull the plug

This is the one everybody should know, because it needs nothing.

1. Open the tool’s page and wait for it to load fully.
2. Turn off your Wi-Fi or switch on airplane mode. Do not reload the page.
3. Use the tool. Drop a file in and run it.

If it works — a result appears and downloads — then the processing happened on your device. There is no third option. A server cannot be reached over a connection that does not exist.

If it fails, that is not automatic proof of uploading. Some genuinely local tools fetch a chunk of code the first time you use a particular feature, and that fetch will fail offline. So retry it in the fair order:

1. Reconnect and load the page.
2. Use the tool once while online, so anything it needs on demand arrives.
3. Now disconnect and use it again.

If the second attempt works offline, everything needed is on your machine. If it still cannot function without a connection, the work is being done elsewhere.

Test 2: watch the network panel

More work, and it removes all doubt.

Open developer tools — F12 on Windows and Linux, Cmd + Option + I on a Mac — and pick the Network tab. On a phone this is not available; use test 1.

1. Load the page, then clear the network log using the circular icon.
2. Drop your file in and run the tool.
3. Read the list.

You are looking for one thing: a request whose outgoing size is roughly your file’s size. Sort or look at the size column. A 3 MB image being uploaded shows up as a 3 MB request. It cannot hide, because the browser is the thing doing the sending and the thing doing the reporting.

What you will legitimately see, and should not be alarmed by:

• Downloads of code. A PDF library or an image decoder is often fetched the first time it is needed. This can be several hundred kilobytes and the size column will show it — but it is arriving, not leaving, and it happens once.
• Fonts, stylesheets, icons. Small, and they load with the page.
• Analytics and ads. Often present, usually a few kilobytes, and worth knowing about for their own reasons — but they are not your document.

The distinction that matters is direction and size together. Click any request and look at the Headers panel: a POST or PUT carrying a request body the size of your file is an upload. A GET returning a body is a download.

Test 3: check the arithmetic

Some sites will tell you they process locally and send telemetry — page views, error reports, which button you pressed. Those are different things and it is reasonable to want to know which you are looking at.

The arithmetic settles it. Analytics events are hundreds of bytes to a few kilobytes. Your file is hundreds of kilobytes to tens of megabytes. There is no way to transmit a document in a 400-byte request. If nothing left that is within an order of magnitude of your file’s size, your file did not leave.

Drop in the biggest file you have handy when you run test 2. The bigger the file, the more obvious the answer.

Test 4: how long did it take?

The weakest test, but a useful instinct.

Uploading takes time, and home and mobile connections upload far more slowly than they download — often five to ten times slower. A 10 MB file over a typical domestic connection takes meaningful seconds to send, then the server has to work, then the result comes back.

So when a 10 MB PDF is compressed the instant you drop it, on a phone, on mobile data, in a tunnel — no network round trip happened. Treat that as a strong hint and then confirm with test 1.

Conversely, slowness proves nothing. Local processing on an old phone can be genuinely slow, because your device really is doing the work.

What none of these tests tell you

Being honest about the limits:

• They test this page, today. A site can change. If it matters, retest.
• They do not audit the code. You are checking behaviour, not intent.
• A determined liar could store now and send later. Test 2 would catch it on the next visit, but test 1 alone would not.
• They say nothing about the download. If a tool gives you a link to fetch your result from a server rather than a file your browser produced, the file was on a server. A local tool hands you a blob your own device created.

For genuinely high-stakes documents, the only complete answer is a device that has never been connected. For everything else, tests 1 and 2 are proportionate and they are far better than reading a badge.

The five-question version

If you want a checklist rather than a method, ask:

1. Does it work offline after one online use?
2. Does anything file-sized leave while it runs?
3. Is the result produced by my browser, or fetched from a URL?
4. Does the privacy policy describe uploads? A truly local tool has no uploads to describe, and its policy usually says so plainly rather than promising deletion timelines.
5. Is there any mention of a retention period? A retention period is a statement that files are retained.

Question 5 is the quietest tell. A site that says “your files are deleted after one hour” is telling you your files were stored for up to an hour. A site with nothing to store has no timeline to offer.

Related reading: what actually happens to your file when you upload it.