How to Verify a Web App Never Uploads Your Files (a 2-Minute DevTools Check)

Plenty of tools claim your files "never leave your browser." It's a great promise — and one you should never take on faith. The good news is you don't have to. Any web app that truly processes files locally leaves an unmistakable fingerprint: it makes no network request carrying your file's contents. You can confirm that in about two minutes with tools already built into your browser. Here's exactly how, and how to run the check on this very site.

The two-minute DevTools check

1. Open the tool you want to test in a normal browser tab (Chrome, Edge, Firefox, or Safari all work).
2. Open Developer Tools: press F12, or Ctrl+Shift+I (Windows/Linux) / Cmd+Option+I (Mac). In Safari, first enable the Develop menu in Settings → Advanced.
3. Click the Network tab. This logs every request the page makes.
4. Click the clear button (the ⊘ icon) to empty the log so you start from a clean slate.
5. Now do the thing that would upload your file — load two documents and run the comparison.
6. Watch the request list as the result appears. Look specifically for any request whose type is a document/file POST, or that shows your file size in the Size column going out.

If the file is being sent to a server, you'll see it: a POST (or PUT) request, usually to an /upload, /api, or /convert endpoint, with a request payload roughly the size of your file. If the tool is genuinely local, you'll see the opposite — the result appears instantly and no request carries your file. That absence is the proof.

How to read what you see

Click any request to inspect it. The panels that matter:

1. Headers — check the request method and URL. A GET fetching a script is normal; a POST of your file to a server is the thing you're looking for.
2. Payload / Request — this shows what was actually sent. If your document's bytes are in here, it was uploaded. If there's no payload, or only tiny bits of telemetry, it wasn't.
3. Size column — sort by it. An upload of a multi-megabyte PDF shows a multi-megabyte request. Local processing shows nothing of the sort leaving the page.

The tell-tale sign of local processing: you pick a big file, the result is essentially instant, and the Network tab stays quiet apart from static assets. A server round-trip for a large file is never instant — the upload alone takes time you'd see in the waterfall.

Closing the loopholes

A careful reviewer checks a few more things so a tool can't sneak an upload past the obvious view:

1. Turn off request filters. Make sure the Network tab is showing "All", not just "Fetch/XHR", so nothing is hidden from you.
2. Watch the whole session. Some tools defer the upload — leave DevTools open and keep watching for a beacon fired a few seconds later or on page unload (check the "Preserve log" box so nothing clears).
3. Look at WebSocket and beacon traffic. Uploads don't have to be classic POSTs. The Network tab still lists WebSocket (WS) frames and navigator.sendBeacon calls — inspect anything with a suspicious payload size.
4. Try it offline. The strongest test of all: load the page, turn off your Wi-Fi, and run the comparison. If it still works with no network, the processing is unquestionably local. A tool that uploads simply can't produce a result offline.

The offline test is the one that ends the argument. A tool that needs a server to compare your files cannot do it with the network switched off. If it keeps working, the files never went anywhere.

Run it on this tool

We'd rather you verify than believe us. Open the document comparison tool, the spreadsheet comparison tool, or the screenshot comparison tool, start a network capture, and run a real comparison. You'll watch two files get diffed with zero upload requests — and if you flip your Wi-Fi off first, it'll still work. That's the whole point: the privacy claim here isn't a policy you have to trust, it's a behaviour you can observe.

This is also the practical backing for the compliance argument in our post on GDPR and file-comparison tools: a tool that provably never transmits your file removes the transfer entirely, rather than promising to delete it afterward.

Frequently asked questions

How do I check if a website is uploading my file?

Open your browser's developer tools, go to the Network tab, clear the log, then perform the action that would upload the file. If you see a POST or PUT request carrying a payload roughly your file's size, it's uploading. If no request carries the file, it's processing locally.

What does it look like in DevTools when a file isn't uploaded?

The Network tab shows only static assets (scripts, styles, fonts) and maybe small analytics pings — nothing with a large request payload. The result also appears effectively instantly, because there's no upload time. Picking a large file and getting an immediate answer is a strong local-processing signal.

Can a tool hide an upload from the Network tab?

It's very hard to hide from a determined check. Set the filter to "All", enable "Preserve log", and watch for deferred beacons and WebSocket frames. The definitive test is to disconnect from the network entirely — a tool that still works offline cannot be uploading anything.

Does the offline test really prove local processing?

Yes. If the app produces a correct result with the network switched off, no server was involved in the computation, so your files never left the device. It's the simplest and most conclusive check available.

Which browsers can I use for this check?

All the major ones. Chrome, Edge, and Firefox expose DevTools via F12 or the keyboard shortcuts above. Safari works too once you enable the Develop menu in Settings → Advanced. The Network tab behaves the same way in each.