Why We Refuse to Upload Your Images

There is an uncomfortable irony at the centre of most image-verification services: to find out whether a sensitive image is real, you must first send that sensitive image to a stranger’s server.

For a lot of users, that trade is simply unacceptable.

Who cannot make that trade

• Journalists holding a leaked photograph from a source who would be identified if the file surfaced.
• Lawyers with evidence subject to privilege or a protective order.
• Moderators reviewing intimate imagery reported for non-consensual distribution.
• Insurers and investigators handling claimant data under strict retention rules.
• Anyone in a jurisdiction where the server’s jurisdiction is a legal problem.

These are precisely the people who most need verification, and precisely the people a conventional upload-based service excludes.

The architecture

Our detector performs every calculation in the visitor’s browser:

1. The file is read into memory with the FileReader API — the same mechanism that powers a local image preview.
2. It is drawn onto an offscreen HTML5 <canvas>.
3. Pixel data is read back with getImageData and analysed by JavaScript running on your own CPU.
4. Results are rendered into the page.

At no point is there an HTTP request carrying image data, because there is no endpoint to receive one. This is not a retention policy that we promise to honour — it is an absence of capability.

How to verify the claim yourself

Do not take our word for it. Open your browser’s developer tools, switch to the Network tab, clear it, and run an analysis. You will see requests for fonts and page assets, and no request carrying your image. You can also disconnect from the network entirely after the page loads: the detector keeps working.

That auditability is the point. A privacy claim you can check in thirty seconds is worth more than a privacy policy you have to trust.

The trade-offs, honestly

Client-side processing is not free of cost:

• Compute is yours. A large image on an old phone is slower than it would be on our server.
• Model size is constrained. We cannot ship a multi-gigabyte neural network to every visitor, which is why our engine uses efficient classical forensics rather than a large learned model.
• No cross-image intelligence. We cannot compare your image against a corpus of known fakes, because we never see it.

We think those are the right trade-offs for this product. A tool that is slightly less capable but actually usable by the people who need it most beats a more capable tool they are forbidden to touch.