Don't trust us. Check.

Every file tool on the internet claims to respect your privacy. Claims are free. Here are four ways to establish, in ascending order of effort, that this one is telling the truth — including two that take under a minute.

1. Watch the network (30 seconds)

Open your browser's developer tools with F12, select the Network tab, and leave it open while you process a file.

You will see the requests that loaded the page itself — the HTML, the stylesheet, the two scripts — and then nothing further. No request appears when you add a file, and none appears when you download the cleaned copy. If this site were uploading anything, it would be in that list, because there is no way to send data from a web page that the Network tab does not show.

If you do see an unexpected request, suspect your extensions first. Browser extensions inject code into every page you open, and their traffic shows up in your Network tab looking exactly like ours. Some of them rewrite the page itself: open this site's sitemap with extensions enabled and you may find an injected <div> in it that is nowhere in the file we publish.

So run the test in a private or incognito window, which disables extensions by default. That is also the fairer test of us — it isolates what this page does from what your browser is doing around it.

2. Pull the plug (30 seconds)

Load a tool page, then disconnect from the internet — turn off Wi-Fi, unplug the cable, switch on aeroplane mode, whichever is easiest. Now use the tool.

It works normally. A tool that needed to send your file somewhere could not possibly behave that way. For the strongest version of this test, save the page to disk first (Ctrl/Cmd+S), disconnect, and open the saved copy from your own filesystem.

3. Read the code

The processing logic lives in one file of plain, commented JavaScript with no dependencies and no build step. What is published is exactly what is written — there is no minified bundle hiding anything.

metadata.js — the parser and stripper
app.js — the interface around it

If you would rather not read all of it, search it. The complete set of ways a browser can transmit data is small, so a handful of searches settles the question:

fetch(          XMLHttpRequest    sendBeacon
WebSocket       EventSource       navigator.
new Image(      form              action=

None of them appear in the processing code. The only network requests this site can make are the ones your browser makes to load the page.

Can't read JavaScript? Have an AI read it to you

Most people who need this tool are not programmers. You can hand the source to ChatGPT, Claude, Gemini or whichever assistant you use, and have it do the reading. The trick is asking a question with a checkable answer. Do not ask "is this site safe?" — that invites a reassuring guess. Ask it to find specific things and quote them, so you can tell whether it actually looked:

Fetch these two files and answer strictly from their contents:

https://raw.githubusercontent.com/misterclarity/biz/HEAD/docs/tools/image-metadata/metadata.js
https://raw.githubusercontent.com/misterclarity/biz/HEAD/docs/tools/image-metadata/app.js

1. List every line that could send data off the machine — fetch,
   XMLHttpRequest, sendBeacon, WebSocket, EventSource, a Worker, a
   dynamic import, a form submission, or setting .src on an element.
   Quote each line with its number, or state plainly that there are none.
2. What does the code do with the file the user selects?
3. If you could not retrieve either file, say so instead of guessing.

Point three matters most. An assistant that could not fetch the files will sometimes answer anyway, from what it assumes a page like this contains. If it cannot quote lines back to you, it has not read anything.

This is the weakest check on this page, and we would rather say so. A language model can misread code or invent details, it is reading the published repository rather than the bytes your browser received a moment ago, and it has no way to observe what actually happens when you use the tool. It is a way to understand the code, not proof about it.

The two tests at the top of this page have neither weakness. Watching the Network tab observes real behaviour, and pulling out the network cable settles the question completely. If an AI's answer ever conflicts with those, believe the network cable.

4. Consider the hosting

This site is served by GitHub Pages, which is a static file host. It serves files and does nothing else — there is no application server, no database, and no way to run code on receipt of a request. Even if the code wanted to upload your document, there is no endpoint here that could accept it.

That is the part we consider most important, because it does not depend on our intentions. A conventional service can promise not to keep your files and then change its mind in a quiet terms-of-service update. This architecture removes the ability, not just the intention.

Where this ends. Verification has limits worth being straight about. You are trusting that the code served today is the code you read, and that your own browser and extensions are not doing something of their own accord. For genuinely high-stakes material, save the page, check it once, and run the saved copy offline from then on. That reduces the trust required to approximately zero.