Don't trust "processed locally" — check it yourself in three steps

Last term I had a batch of coursework images with faces in them, and we'd agreed they weren't leaving the group.

Everything I needed to do to them — compress, convert — pointed at some online tool whose landing page said "secure" and "never stored." I had no way to check that. Then someone showed me the Network tab.

First, be clear about what you're checking

"Upload" means your file went from your machine to their server. The direction is outbound.

There's one thing that gets confused with it constantly: the page downloading something to your browser. Codecs for certain formats, or AI models, get pulled down to your browser and run there. The first time you use one of those features you'll see a request anywhere from tens of KB to hundreds of MB. That's the opposite direction.

I got this wrong on my first attempt — saw a chunky request, assumed my image had been shipped off, and only on a closer look noticed it was a .wasm file fetched with GET.

This is a skill worth having once and keeping: applying for internships, handling ID photos before a job application, converting a medical form. Same move every time.

Step 1: open the Network tab and clear it

F12, or Option + Command + I on a Mac. Switch to Network.

Two things to set up:

1. Tick Preserve log, so a page navigation doesn't wipe your evidence
2. Hit 🚫 Clear and start from an empty list

Step 2: process an image and watch the list

Do the normal thing: pick your file, adjust settings, run it, download the result.

Two columns carry the answer:

• Method. Uploading a file is almost always POST (occasionally PUT). If nothing POSTs across the whole operation, nothing was uploaded.
• Payload. If there is a POST, open it. Either you can see your filename and a wall of binary in there, or you can't. It's not subtle.

Glance at the preview image's source too. Locally-processed tools usually show blob: URLs — that's an object living in browser memory, which never crossed the network.

Step 3: separate downloads from uploads

If you do see something substantial, three tests:

Method is the reliable one. GET fetches something in; POST sends something out.

What I got when I actually ran it

I did this on ImgIng's animation workshop (imging.ai), because I had a pile of GIFs to compress anyway.

• Six animation files, 120×120 up to 720×405, largest 2.62 MB
• Imported, compressed and exported each of them, a dozen-plus rounds
• Result: zero POST requests across the whole session
• Preview URLs were blob:

One thing worth repeating, because it's the honest version: this tool states its own boundary in the interface — common formats run in the browser, but a few professional formats (HEIC writing, TIFF among them) are explicitly marked as server-side, with a differently coloured chip. So "nothing uploaded" holds for the operations I actually performed. You verified your session, not the website.

That's the real takeaway. Verification is scoped to an operation, not to a domain. Different feature, different format, look again.

Three things that trip people up

Analytics POSTs don't count. Plenty of sites fire a few hundred bytes of telemetry. Open the payload — no image content, not an upload.

No POST doesn't mean bulletproof. In principle data could go out over a WebSocket or something more creative. For ordinary web tools, watching POST covers the overwhelming majority of cases. If what you're handling is genuinely sensitive, the stronger move is to pull your network connection and see whether the tool still works — plenty of local-first tools do, and that's a much harder claim to fake.

Open the panel before you start. It only records what happens after it's open. Obvious in hindsight, annoying at the time.

That's it

No frontend knowledge required, nothing to install, about three minutes end to end. Before you drop your ID scan, your coursework data, or a signed document into a website you've never heard of, three minutes is a good trade.