How to check whether a photo has been edited
No tool can show that a photo was never edited. A few signals can show that it was: a signed Content Credentials record that no longer matches the pixels, or metadata that names an editing step. Many photos carry neither, because saving and sharing can remove them, so finding nothing proves nothing.
What can a check tell you about edits?
A file can hold three kinds of evidence about how it was made or changed.
- A signed record. A Content Credentials record is tied to the bytes of the file when it is signed. If the bytes change later, the tie breaks and a validator can see it.
- Unsigned metadata. Fields such as an XMP source type can say that a photo was edited. Anyone can add, change or remove them, so they are labels, not proof.
- Nothing. Many files carry no record and no label. That says nothing about whether they were edited.
Our checker reads the first two kinds. It does not look at the pixels for signs of retouching.
What happens to a signed record when the pixels change?
The C2PA Specification 2.2 calls this tie a hard binding. Section 9.2.1 calls a cryptographic hash over some or all of the bytes of an asset the simplest hard binding that can detect tampering. For box formats such as JPEG, PNG and GIF, section 9.2.2 says a general box hash, which covers the file's boxes (its internal blocks), should be used.
In section 15.5.5, a validator that finds the hard binding does not match shall reject the manifest. The failure codes include assertion.dataHash.mismatch and assertion.boxesHash.mismatch. The same section adds a caution: a mismatch could mean the file was modified, or that the wrong manifest store was located. The code alone does not say which.
The C2PA explainer (section 7.1.3) describes the data as tamper-evident: a change to the file or to the provenance data, however small, makes the two stop matching.
What did we measure when we changed a signed file?
We took two real signed files and changed 12 bytes of image data in each, after signing. One is an Adobe Firefly file (tampered-pixels.jpg); the other is a Microsoft Image Creator file (tampered-boxeshash.jpg). The checker read both as "Content Credentials failed validation". The validator reported a data-hash mismatch for the Firefly file and a box-hash mismatch for the Microsoft file. We measured this on October 30, 2026 in Chrome, with 2 files changed, and the made-file results are on our accuracy page.
| File | What we changed | Validator code | Headline |
|---|---|---|---|
| tampered-pixels.jpg | 12 image-data bytes of a signed Adobe Firefly file | assertion.dataHash.mismatch | Content Credentials failed validation |
| tampered-boxeshash.jpg | 12 image-data bytes of a signed Microsoft Image Creator file | assertion.boxesHash.mismatch | Content Credentials failed validation |
| tampered-ingredient.jpg | Image bytes of the signed earlier version that the file was made from; the file's own pixels are intact | assertion.dataHash.mismatch, in the earlier version | Content Credentials failed validation |
| malformed-manifest.jpg | 32 bytes of the record itself; the picture is untouched | manifest.unreadable | Content Credentials failed validation |
The last two rows matter. The same headline appears when the picture is intact but the record, or an earlier version inside it, is damaged. The line under the headline says more.
Does a record list every edit?
No. The C2PA explainer (section 7.2.1) says provenance is not always complete. If a tool that does not support Content Credentials edits the file, for example to crop it, the edit may go unrecorded. If the file is later brought into a tool that supports them for further changes, the explainer says the signer of the new record also implicitly attests to the earlier crop.
The explainer also says (section 2) that Content Credentials do not give value judgments about whether the data is true. A record that still matches its file shows that the file matches what was signed. It does not show that nothing happened before signing.
What do editing labels in metadata look like?
The IPTC digital source type vocabulary is a list of terms for how media was made. As of October 30, 2026, three of its current terms describe editing, and others describe composites of several elements.
| Term | What IPTC says it covers |
|---|---|
| humanEdits | Correction, enhancement or augmentation by people using non-generative tools. |
| algorithmicallyEnhanced | Changes by an algorithm that do not alter the main content, such as sharpening or noise reduction. |
| compositeWithTrainedAlgorithmicMedia | Correction or enhancement using a generative AI model, such as inpainting or outpainting. |
These are claims that someone wrote into a file. In our tests, a file with unsigned XMP that declares a generative source reads "Metadata declares AI use", and one that declares a camera capture reads "Metadata declares another source". The detail line calls each one a label, not proof.
What happens when a photo has no record?
Then there is no record to compare with the pixels, so a check cannot see edits. A record is stored inside the file, and a tool that writes the pixels out again without carrying the record over leaves it behind. We drew each of the 9 real files that carry a record on a canvas in Chrome and wrote it out again, once as PNG and once as JPEG at quality 0.92. After the PNG, 0 of 9 still read a record. After the JPEG, 0 of 9. All 18 outputs read "No supported provenance signals found". We measured this on October 30, 2026; our accuracy page describes our other tests. This was a browser canvas, not a platform, so it does not show what any site does to an upload.
What this means when you check an image
Open the checker, choose the file, and look at the headline.
- "Content Credentials failed validation" means a record is present but does not validate. When the image changed after signing, the detail says the record no longer matches it and cannot be relied on. It does not say who changed it, when, or whether the change was small.
- "No supported provenance signals found" means we found no record, no source label and no Stable Diffusion watermark pattern. The line under it says this does not mean the image is real or human-made, and the same limit applies to edits: finding nothing does not show that a photo is unedited.
If the checker says a signer is trusted and that the image has not changed since it was signed, that tells you only that the file matches what was signed. If you need more, ask the sender for the original file and read our guide on how to verify a photo someone sent you. The checker's limits line applies throughout: "These checks cannot determine whether an image is AI-generated."
Guides on this topic
- How to tell if an image is AI is the main page on this topic.
- How to verify a photo someone sent you covers what to do with a file you received.
- IPTC digital source type values explained covers editing and capture labels.
- Does a screenshot keep metadata? covers what a re-save drops.
- How to check Content Credentials walks through the other results.
Frequently asked questions
- Can a tool prove a photo was never edited?
- No. A signed record that matches its file shows the file matches what was signed. It does not cover what happened before signing, and most photos have no record.
- If the checker finds nothing, was the photo untouched?
- Not necessarily. Saving, screenshots and sharing remove records and metadata. In our test, none of 9 records survived a canvas re-save.
- Does "failed validation" mean the photo was edited?
- It means the record does not validate. In our test files it appeared for changed pixels and for a damaged record. Read the line under the headline to tell them apart.
- Does the checker look at pixels for retouching?
- No. It reads signed records, metadata and one invisible watermark pattern. It does not analyse pixels for signs of editing.