Methodology: how we measure, and what we won't claim

This page documents what the tools actually do, from the code that runs them. When the implementation changes, this page changes with it, and tests fail if the two drift apart.

The reference engine

Files are read with ExifTool, the reference metadata engine photographers and forensic analysts have used for over twenty years (version 13.x at the time of writing, from the Debian package our container installs). We did not write our own parser, and we did not build on a partial one: ExifTool covers the EXIF, IPTC and XMP layers, MakerNotes, embedded thumbnails, colour profiles and the AI-provenance fields.

Reading is done with ExifTool’s group output (-G, family 0), which is why a GPS coordinate arrives named EXIF:GPSLatitude rather than GPS:GPSLatitude in raw listings. The interface translates that into plain-language groups; the group prefix itself matters internally because removal selectors are resolved against it.

The privacy exposure score, as implemented

The score answers one question: how much would this file tell a stranger? It starts at 100 (nothing to report) and drops as sensitive fields are found. The implemented weights:

Signal found	Effect on the score
GPS coordinates	−40
Mobile-network country (no GPS present)	−20
Device, lens or camera serial number	−20
Owner, artist or author name	−15
Each further sensitive field	−3, capped at −15

The score floors at 0. A file at 100 reveals none of the tracked signals; the bands are “ok” from 80, “medium” from 50, “high” below.

The sensitive-field list includes GPS location, device / lens / camera / internal serial numbers, owner name, author name (EXIF and IPTC forms), creator name, and the mobile-network country field some phones write (MCCData). That last one exists because a measured Samsung Galaxy S24 photo carried no GPS at all yet named the country the phone was connected to - a “nothing to report” on a photo that discloses a country would be a false reassurance.

Two exclusions are deliberate:

• The File group (file name, size, timestamps) is excluded from every count. It describes the file on disk rather than the photograph, and it changes on every operation because results are new temporary files.
• The ICC_Profile group is excluded from sensitive-field flagging. Its ProfileCreator field names the colour-profile vendor, not the photographer; flagging it produced exactly the false positive the score must not produce, and the colour profile is preserved on purpose because stripping it shifts colours.

One invariant ties the score to the cleaning tool: everything the score flags can be removed by the privacy recipe. A regression test writes each family of sensitive data into an image, applies the recipe, and requires an empty sensitive list afterwards. Copyright is deliberately not a sensitive signal - it is a rights claim published on purpose.

The AI-trace rules, as implemented

The checker reads the metadata layer only, looking for four families of signals:

1. C2PA / Content Credentials - a byte-level scan for the JUMBF container (JPEG APP11) and the caBX PNG chunk, plus C2PA-related tags in the XMP layer.
2. IPTC/XMP digitalSourceType - the standard field whose value trainedAlgorithmicMedia declares the file as generative-AI output.
3. Generation parameters - the parameters text chunk that Stable Diffusion (AUTOMATIC1111) writes, decoded into prompt, negative prompt and settings, and the prompt / workflow chunks ComfyUI writes.
4. Declared software - the Software / CreatorTool fields, which often name the generator outright.

Signals from the first three families are treated as strong evidence; a declared software name alone is weak evidence, because anyone can write any name into a field. The interface never converts this into a percentage: a file with at least one strong signal reports “AI traces found”, one with only weak signals reports “Inconclusive”, and a file with no signals reports “No AI traces in metadata (this does not prove the image is real)”. That last wording is the honest one - screenshots, messaging apps and format conversions strip metadata as a routine side effect.

Pixel-level watermarks such as SynthID are invisible to all of this. We state that on the tool itself.

How this site is written

Every number on this site comes from a file we opened and read, or from a cited standard. When we cannot measure something ourselves, the page says what the standard does and stops there.

Test protocol

Our platform tests (what each messaging app and social platform keeps or strips) follow one protocol: a real photo is sent through the platform, the received file is retrieved, and both copies are read field by field with the same engine described above. The recorded field counts and the evidence screenshots become the data behind each guide.

The full written protocol - devices, app versions, and per-platform procedures - is being finalised with our first platform-test series and will be published here. Until then, each published guide documents its own exact test inline.