How to tell if a browser tool really processes your photo locally

Start by separating three promises that marketing copy routinely blends into one, because they are not the same and they are not equally true of most tools:

1. Your file bytes are never transmitted. The image is read from disk into the page's memory, processed there, and written back out. This is the claim that matters for the photo, and it is the one you can test.
2. The page makes no network requests at all. Almost no public website satisfies this. Analytics, ads, fonts, and error reporting all talk to servers. Conflating this with the first promise is what causes most false accusations.
3. The operator learns nothing about you. Weaker still. A site can be entirely honest about never receiving your photo while its analytics record that you visited a page about removing GPS data.

Keep those numbered apart as you read. A tool can pass the first test convincingly and fail the second and third, and that is the normal state of affairs — including here.

The checks, easiest first

1. Cut the network and work anyway. This is the best return on effort of anything on this page. Open the tool and let it finish loading. Now disconnect: Wi-Fi off, or the cable out. Then pick your file, run the wipe, and download the result. If a cleaned copy appears and saves with no connection available, no remote machine was involved — there was nowhere for the file to go. It requires no technical knowledge and it is difficult to explain away.

Two things to expect. First, you must load the page before disconnecting. MetadataWipe registers no service worker, so it keeps nothing cached for offline use; reloading while disconnected will produce an ordinary browser error, which tells you nothing bad about the tool. Second, some tools genuinely do need the network for a legitimate reason — pulling down a large processing library on demand, for instance. A tool that stalls offline is not automatically dishonest, but it has failed to demonstrate the thing you were trying to confirm, and you are entitled to treat an undemonstrated claim as unconfirmed.

2. Watch the traffic while you work. Desktop browsers include developer tools with a panel that logs network activity; the exact name and location vary by browser and version, so look for the developer or web inspector menu. Open it, clear the log, and then do the whole job — select the file, run the wipe, download. You are reading for one thing: an outbound request whose body is roughly the size of your image, going to an endpoint that looks like a processor. A 6 MB photo cannot be sent for processing in a 400-byte request. You will also see requests unrelated to your file, which brings us to the honest disclosure: MetadataWipe's own pages load Google Analytics and Google AdSense, so traffic to Google domains is expected and is not your photo.

3. Check where the download actually points. This one is quick and quietly decisive. If a tool's download link or button resolves to a blob: address, the bytes were assembled inside the page and handed to your downloads folder from local memory. If it points at something like https://example.com/tmp/output-9f2c.jpg, then a server built that file, which means a server had your image. MetadataWipe's cleaned export is delivered from an object URL created in the page from the in-memory result.

4. Sanity-check size and speed. Physics is a decent auditor. Drop in a deliberately large file on a connection you know is slow. Remote processing means a round trip: your file up, a result back. If a 40 MB image is cleaned effectively instantly while your connection is crawling, it was not round-tripped. Conversely, a tool whose processing time scales suspiciously with your bandwidth rather than with your CPU is telling you something.

5. Look at what the page loads. View the page source and read the script tags. You are not auditing an application; you are counting how many parties are involved. A tool whose logic is one first-party script plus a couple of well-known third-party tags is a smaller surface than one pulling in a dozen scripts from hosts you have never heard of. You do not need to understand the code to notice that.

6. See whether there is a Content-Security-Policy. This is the most rigorous check and the one most likely to come back inconclusive. A site can send a security policy header that restricts the destinations its own pages are permitted to contact; where such a policy is tightly written, it becomes a limit the browser enforces rather than a promise the operator makes. It is worth knowing this exists so you can recognise it when you see it. In plain honesty, though: most sites do not publish one, and MetadataWipe currently does not. Absence is not evidence of uploading — it is the absence of that particular machine-checked assurance, which is a different and much weaker finding.

What none of these checks can establish

Every result above describes the code your browser received on this visit. A website is not a shipped artefact; it can be rewritten between one load and the next, so today's clean observation is not a standing guarantee about tomorrow's version. Nor can a short session rule out a page that buffers data and transmits it under conditions you never triggered. These are limits of the method, not reasons to skip it — a check that raises the cost of misbehaving and catches the obvious cases is worth running even though it is not a proof.

Where the stakes are real, the sturdier answer is a tool you can hold still: an open-source program installed on your own machine, inspectable at the source level and constrainable with a firewall. That is the trade-off discussed on the ExifCleaner alternative page — a browser tab wins on convenience and loses on auditability, and for a leak submission or a court exhibit the second may matter more. Separately, none of this tells you whether the wipe worked; confirming that the tags are actually gone from the output is its own task, covered in the guide to verifying metadata was removed. Trusting the tool and checking the result are two different jobs, and doing one does not excuse the other.

Common mistakes and misconceptions

"The Network panel lit up, so it's uploading my photos." The most frequent error, and the reason people abandon tools that were behaving correctly. Requests to analytics and ad hosts are not image transfers. Read the destination and the payload size before drawing a conclusion.

"It's HTTPS, so my file is safe." HTTPS protects a transfer; it does not prevent one. A site that receives your photos over a valid certificate has still received your photos.

"The site says no upload required, and it has a privacy policy." Both are statements of intent, and a policy is a promise about conduct rather than a constraint on code. They are worth reading and they are not the same category of thing as an observation you made yourself.

"Local processing means nobody knows what I did." It means nobody received your file. Your visit can still be logged by the site's analytics, your network operator can see which domain you loaded, and the cleaned file lands in your downloads folder where anything with access to your device can find it. Local is a statement about the file's path, not about your anonymity.

"Open source means local, and closed means remote." Neither follows. Published source you never read is not an audit, and plenty of closed pages do their work entirely in the browser. The behaviour is what you are testing; the licence is a different variable.

What this tool actually does

So the checks above have something concrete to land on: MetadataWipe accepts JPEG and PNG images, one file at a time. It runs a quick heuristic scan over the beginning of the file to flag likely metadata markers — a fast screen, not a forensic audit — then produces the clean copy by drawing the decoded image onto a canvas and re-encoding it, which is why the export is a browser-generated file rather than an edited version of your original. The result is offered as a download from an object URL built in the page, with -metadatawipe appended to the original base name. The script that does this work makes no network calls; the surrounding page, as noted, carries analytics and advertising that do.

Related guides

See also:

• ExifCleaner alternative that runs in your browser
• How to verify metadata was removed