Verification

How to verify metadata was actually removed

Published September 18, 2026 · Updated September 21, 2026 · MetaPurify

Almost every metadata tool ends the same way: a green tick and the word "done". That is the tool reporting on its own work. It is a claim, not evidence — and the difference matters when the thing you were removing was your home address.

Why "removed" is a claim, not proof

A cleaner can report success and still leave data in the file. Three failure modes account for most of it.

Partial coverage. A tool that clears the EXIF block may not touch the XMP packet next to it. Editing software frequently writes the same information into both, so a photo with its EXIF GPS removed can still carry exif:GPSLatitude inside an XMP packet that the tool never opened.

Structures the parser cannot see. Metadata libraries report what they can decode. If a rewrite corrupts an EXIF block rather than removing it, a second pass may fail to parse it and report nothing found — which looks identical to success.

Compressed records. PNG stores text in three chunk types: tEXt is uncompressed, zTXt is zlib-compressed, and iTXt may be either. A tool that reads only tEXt will report a clean file that still contains an entire Stable Diffusion prompt inside a zTXt chunk.

In all three cases the user interface says the same thing.

Checking a cleaned file yourself

You do not have to take any tool's word for it, including ours.

Use a second, independent tool. The most direct check is to open the cleaned file in a different reader than the one that cleaned it. ExifTool is the reference implementation, and we compare against it directly; exiftool -a -G1 -s cleaned.jpg lists every tag it can find, grouped by the structure it came from. Our own metadata viewer works as an independent second opinion on a file cleaned elsewhere.

Compare against the original. Run the same command on both files and diff the output. A list of what disappeared is far more informative than a list of what remains.

Treat file size as a hint, not an answer. A file that shrank by 12 KB probably lost something. A file that shrank by 200 bytes might have lost a timestamp, or might have lost nothing and been repacked. Size tells you that something changed, never what.

Look at the raw bytes if you want certainty. Metadata is text far more often than people expect. strings cleaned.png | head -50 will show a surviving prompt or copyright notice immediately, without needing any parser to cooperate.

What MetaPurify compares

Our cleaner does not mark its own homework by remembering what it intended to do. After writing the output it throws that intention away and re-examines the resulting bytes.

Four things are checked, and each catches a different failure:

1. The output is reparsed from scratch. The cleaned bytes go back through the same inspection the original file received. The "after" report is produced by reading the new file, not by subtracting from the old one.
2. Every selected category is diffed. Each category you asked to remove is checked against the categories still present in the new report. Anything that survives is listed by name as retained, not quietly dropped.
3. Container structures are checked at byte level. This is the backstop for the second failure mode above. Even when the parser can no longer decode a block, the file is scanned for the raw container types that back each category — eXIf, tEXt, zTXt, iTXt and tIME in PNG, the EXIF, XMP, IPTC and comment segments in JPEG, the EXIF and XMP chunks in WebP. A structure that is still physically present counts as retained even if nothing can read it any more.
4. Surviving XMP is scanned for coordinates. When GPS removal is selected, any XMP packet left in the file is checked byte-wise for location properties. That closes the EXIF-clean-but-XMP-dirty gap specifically.

Separately, the compressed image payload is hashed before and after cleaning and the two digests are compared. That is what backs the claim that cleaning does not re-encode your photo: if the hashes differ, the interface says so rather than assuming. See does removing metadata reduce image quality for why that distinction matters.

When verification says it could not confirm

There is a deliberate third state between "verified" and "failed".

If an EXIF block is left unedited — because it could not be rewritten safely — the result is not reported as verified, even when the parser finds nothing objectionable in it. The file still processed, you can still download it, but the interface says the removal could not be confirmed for that block rather than showing a tick it has not earned.

The same applies when you keep orientation. Preserving rotation means writing back a minimal EXIF container holding one tag, so an EXIF structure remains in the file by design. That case is distinguished from a failed removal rather than being lumped in with it.

An honest "could not confirm" is more useful than a confident tick, because it tells you exactly where to look with a second tool.

What verification cannot tell you

Verification is a statement about bytes in a file. It says nothing about:

• Anything visible in the photograph. A street sign, a house number, a reflection or a recognisable skyline survives every metadata operation ever written.
• Pixel-level watermarks. Provenance marks such as SynthID are encoded into the image data itself. Metadata removal does not touch pixels, so it does not touch them.
• Copies that already exist elsewhere. If the original reached a platform, a backup or a recipient, cleaning your local copy changes nothing about theirs.
• What a platform records about the upload. Account, device, IP address and timestamp are the platform's own data, not fields in your file.

Verification answers one narrow, checkable question: is the data still in this file? That question deserves a real answer instead of a green tick — but it is not the only question worth asking.