remove‑exif

How to verify a privacy tool isn't uploading your file

Published 19 August 2026

"Runs in your browser. Nothing is uploaded." Every tool in this category says it, including this one. You should not take that on faith — from any of us. This page teaches you how to check it yourself, on any tool, in about two minutes, using nothing you don't already have installed.

A promise is not a guarantee

"We don't upload your file" can mean two very different things. It can be a policy — a sentence in a privacy page, true until a bug, a new feature, or a new owner makes it false, and you would have no way to know when that happened. Or it can be architecture — a technical constraint that makes uploading impossible regardless of what the code tries to do, verifiable by anyone with a browser and five minutes.

Almost every tool in this space offers the first kind. This page shows you how to tell the difference, and how to check which kind you're actually getting — starting with a tool everyone already has: your browser's own developer tools.

Open the Network tab before you touch any tool

Every modern browser ships a network inspector built for exactly this. Open it before you use the tool you're checking, not after — requests that fire while you weren't looking are the ones that matter.

Click the Fetch/XHR filter if your browser offers one. It hides the page's own scripts, styles and images so you're left watching for the thing that actually matters: a request that fires after you hand the tool a file.

What it looks like when a tool uploads your file

Drop a file into the tool you're testing and watch the panel. An uploading tool shows a new request appear at roughly the moment you drop the file, with a method of POST or PUT, a request size in the same order of magnitude as your file, and a response that arrives only after some processing delay. Click it and open the Payload or Request tab — for an image or document upload, you'll often see the raw bytes or a base64 blob roughly your file's size.

Two things to watch for that a quick glance misses. First, some tools use a WebSocket instead of a normal request — check the WS tab too, not just Fetch/XHR, since a single open connection can carry file data without ever showing up as a discrete request. Second, some fire the request on a delay — a few seconds after you'd naturally stop watching — specifically to survive a cursory check. Leave the panel open for at least thirty seconds after the tool finishes.

What it looks like when remove-exif.com processes a file

Do the same thing here: open the Network tab, filter to Fetch/XHR, then drop a photo into any format page — /images/jpg is a good one to try. Watch the request count while the file is read, its metadata listed, and the cleaned version prepared for download.

Nothing appears. Not "nothing we noticed" — the request count stays at the exact number it was before you dropped the file in, for as long as you leave the tab open. That is the outcome an uploading tool cannot produce, no matter how it tries to hide the request, because on this site the code that touches your file cannot make one at all — which is a stronger claim than "didn't", and the next two sections show you how to check the stronger claim specifically, not just the absence of a request in one test.

A false positive worth knowing about, here specifically

This site is funded by advertising, and the outer page — the one showing this text — loads ad requests to Google's domains. Those are real, they show up in the Network tab, and they have nothing to do with your file: they fire on page load whether or not you ever touch the tool. If you see them and assume the worst, you'd be testing the wrong thing.

What actually matters is which frame made each request, not whether the tab has any entries at all. Check the Initiator column, or open a request and look at its origin: advertising and the page chrome load from the top-level document; your file is handled entirely inside the embedded frame at /sandbox/, and that frame is the one this page's tests are about. The two are kept separate for exactly this reason — so that "advertising loads network requests" and "your file's data left the machine" can never be the same fact, and you don't have to take our word for that separation either; the next two sections show you how to check the sandbox frame specifically.

The stronger test: read the response headers

An empty Network tab during one test is good evidence, but it's still just an observation — the code could, in principle, behave differently on a different run. The header Content-Security-Policy is not an observation; it's an instruction the server sends the browser, and the browser enforces it, full stop.

To see it: in the Network tab, find the request for /sandbox/ — the frame that actually touches your file, loaded invisibly inside every tool page. Click it, open Headers, and look under Response Headers for content-security-policy. You'll find a directive reading connect-src 'none' among others. Per the W3C Content Security Policy Level 3 specification, that directive governs every outbound connection a script in that frame could attempt — fetch, XMLHttpRequest, WebSockets, beacons, EventSource — and 'none' means the browser refuses all of them, unconditionally, before any of them leave your machine.

The strongest test: try to break it yourself

Don't take the header's word for it either. You can make the browser prove it's actually enforcing that policy, live, in about ten seconds.

  1. With DevTools open, go to the Console tab.
  2. Find the context selector — in Chrome it's a dropdown near the top of the Console panel, usually labelled top. Click it and choose the frame whose URL contains /sandbox/.
  3. Type fetch('https://example.com') and press Enter — as if you were the sandbox's own code, trying to send your file somewhere.

The request never leaves. The browser rejects it immediately and logs a Content Security Policy violation naming connect-src 'none' as the directive that blocked it — the exact wording varies by browser, but the outcome doesn't: no network tab entry, no response, nothing sent, because the browser refused to attempt it. You just watched the guarantee hold under a condition more adversarial than normal use — you deliberately tried to make it fail.

Why this works on any tool, not just this one

None of the steps above are specific to remove-exif.com. They work on any web-based tool making a no-upload claim — a background remover, a resume parser, a file converter, anything. Open the Network tab first, use the tool, watch for delayed or WebSocket-based requests, then look for whether the claim is backed by a Content-Security-Policy you can inspect and try to violate, or just a sentence on a privacy page you have to trust.

Most tools you test this way will fail the second half, not because they're lying — most really don't upload your file in ordinary use — but because "didn't, this time" and "structurally can't" are different guarantees, and only one of them survives a bug, a compromised dependency, or a future version nobody reads the changelog for.

This is really a question about architecture, not any single tool — see client-side vs server-side metadata removal for what actually changes when a tool runs in your browser instead of on someone else's server.

Try it on this site right now

Pick any tool page — JPG, PDF, Word, any of them — open the Network tab, and put the three tests above to work. If you find a way to make the sandboxed frame send a request, or the Content-Security-Policy header is missing where this page says it should be, tell us — that would be a bug in the code, not a promise we quietly walked back, and either way you'll have found it yourself instead of taking our word for it.