Content Credentials versus IPTC and XMP metadata: a signed record versus a label
EXIF, IPTC and XMP fields are labels written into a file. Anyone can add, change or delete them, and nothing in the file notices. Content Credentials are a record that is digitally signed and tied to the image's bytes, so a change to the picture or the record is detectable. Neither one proves a claim is true.
What are EXIF, IPTC and XMP metadata?
They are standard ways to store information about a picture inside the picture file. The C2PA explainer (section 7.4.2) says Content Credentials are used in conjunction with them.
One IPTC field matters most for this topic. IPTC's Photo Metadata User Guide says the Digital Source Type field indicates the media source from which the digital image was created. Its values come from a controlled list, the IPTC Digital Source Type vocabulary. That page defines trainedAlgorithmicMedia as digital media created algorithmically using an artificial intelligence model trained on captured content, and digitalCapture as media captured from a real-life source using a digital camera or digital recording device. The guide lists Digital Source Type among the fields that go only to the XMP structure.
What makes Content Credentials different?
Two things: a signature and a binding. The C2PA explainer (section 7.1.3) says the provenance data is tamper-evident. It combines standard cryptographic hashes with a digital signature made with X.509-based credentials. Section 6.2 adds that if any part of a credential is altered, one or more hashes no longer match. Editing the pixels breaks the match too.
An unsigned label has no signature to break, so a changed or deleted label looks the same as an original one.
We tested the signed side. We changed 12 image-data bytes in a real Adobe Firefly file and in a real Microsoft Image Creator file. The checker read both as "Content Credentials failed validation": the image no longer matched its record. A label cannot show that.
The explainer is also clear about limits. Section 2 says Content Credentials do not judge whether provenance data is true, and section 7.2.3 answers "Yes it can" to whether provenance can be removed. A signed record shows who signed and that the bytes match. It does not show the claim inside is correct.
Does C2PA use IPTC too?
Yes. The same IPTC vocabulary appears in more than one place, and the place decides how much it is worth.
| Where it sits | Who can change it | What our checker shows |
|---|---|---|
The XMP property Iptc4xmpExt:DigitalSourceType, outside any record | Anyone, with an ordinary metadata editor, without breaking anything | "Metadata declares AI use" (or "Metadata declares another source"), tier "Declared" |
The digitalSourceType field of an action inside a signed record | Someone who re-signs the record under their own certificate; an edit without re-signing breaks the match | A record headline; the claim is read as "The signed record says ..." |
The second row follows C2PA Specification 2.2. Section 18.14.4.5 says the value of an action's digitalSourceType shall be an IPTC term or one of a short list of C2PA values. Appendix B.2.3 also lists the XMP property Iptc4xmpExt:DigitalSourceType among the IPTC Extension properties its metadata assertion supports. The name is shared; the protection is not. A source type is only as strong as its container.
What did our test files show?
We made three test pictures to put the same claim in different containers. The checker read each once in Chrome on October 30, 2026. Our accuracy page lists the files we made.
- Unsigned XMP only. The file's only provenance information is an XMP source type of
trainedAlgorithmicMedia. The checker reads "Metadata declares AI use", with a line saying anyone can add or remove it: a label, not proof. - The same claim in a signed record. A second picture carries a record declaring
trainedAlgorithmicMedia, signed with a certificate we made ourselves. It reads "Content Credentials found; signer trust not established". The record matches the image, but no trust list we load vouches for the certificate. - A label and a record that disagree. A third picture has a signed record declaring a camera capture and an XMP label, written before signing, declaring
trainedAlgorithmicMedia. The record headline stays; the disagreement appears as a "Declared" finding labelled "Conflict".
The same claim reads differently by container. A signed record outranks an unsigned label in our headline, because only the record can be checked. These results are about our checker and files we made.
What do real files show?
Among the 32 real files in our test set, 8 carry an IPTC source type inside a signed record or the record of an earlier version of the image: 7 declare trainedAlgorithmicMedia and 1 declares compositeWithTrainedAlgorithmicMedia. One file filed under "Images generated by Gemini" in Wikimedia Commons carries the declaration only as unsigned XMP, and reads "Metadata declares AI use". Seven of these nine files came from Wikimedia Commons, uploaded by third parties, and two are vendor samples. How the Commons files were handled before upload is unknown.
Records are fragile too. We re-drew the 9 real files that carry a record on a canvas and saved each again as PNG and as JPEG, which is what a screenshot or a re-encode does to the pixels. None of the 18 outputs kept a record, and all 18 read "No supported provenance signals found", so the checker found no metadata in them either. We used one browser and one JPEG quality, and contacted no platform.
Is IPTC metadata worthless, then?
No. A label is weak evidence with real uses. Google's help page "Preserving metadata tags for AI-generated images in Merchant Center" says that AI-generated images used in Merchant Center, such as in the image link attributes of product data, must contain the IPTC DigitalSourceType trainedAlgorithmicMedia tag, and it tells merchants not to remove such tags. Here the label is a disclosure a system can read. It proves nothing.
What this means when you check an image
Open the checker, choose the file, and read the headline first.
"Metadata declares AI use" means the file carries an unsigned label saying so. It is a statement anyone could have written or removed. It tells you what the file says about itself, not whether that is accurate.
"Content Credentials found; signer trust not established" means a signed record is present, but no trust list we load vouches for its certificate. The line under it says why, for example that the certificate is on neither list or has expired. The claims inside are the claims of whoever holds that certificate.
Finding nothing is limited too. "No supported provenance signals found" does not mean an image is real or human-made. The checker's limits line always applies: these checks cannot determine whether an image is AI-generated.
Guides on this topic
- What are Content Credentials? is the main page on this topic.
- IPTC Digital Source Type values explained defines each term.
- Where AI declarations live in an image file maps the containers.
- Can EXIF data be faked? covers unsigned metadata.
- Can Content Credentials be faked? covers self-made certificates.
Frequently asked questions
- Are Content Credentials just metadata?
- They are metadata that is signed and bound to the image. The C2PA explainer says they are used alongside IPTC, XMP and EXIF.
- Can I trust an IPTC label over a signed record?
- Not over it. Our checker lets a signed record outrank an unsigned label, because only the record can be checked. A record is not proof either, since the C2PA explainer says Content Credentials do not judge whether provenance data is true.
- Does removing metadata remove Content Credentials?
- It can. The C2PA explainer says provenance can be removed. In our canvas test, none of the 9 real records survived a re-draw and re-save.
- Why does the same IPTC term appear in both?
- C2PA reuses the IPTC vocabulary for the source type of an action in a signed record. It is one list of terms in two containers of different strength.