Where AI declarations live in a file: XMP, EXIF, IPTC, PNG text and C2PA, mapped
An image file has several separate compartments where a declaration about how it was made can sit: a signed Content Credentials record, an XMP packet, EXIF tags, IPTC fields and PNG text chunks. Only the signed record can be checked for later changes. The other four are labels that anyone can edit or delete.
Where can an AI declaration sit inside an image file?
The table maps the places our checker reads.C2PA Specification 2.2 puts the signed record in a JPEG APP11 segment (section A.3.1) and a PNG caBX chunk (A.3.2), and recommends a dcterms:provenance key in XMP when the record is stored elsewhere (11.5). The PNG specification defines the text, XMP and Exif chunks (11.3). ExifTool's JPEG table lists EXIF and XMP in APP1 and a Photoshop block in APP13, and its Photoshop table lists IPTC data inside that block.
| Compartment | Where it sits | Can a check show a change? | What our checker shows |
|---|---|---|---|
| Content Credentials record (C2PA) | JPEG: APP11 segments. PNG: a private chunk named caBX. | Yes, it is signed and tied to the image's bytes. | A record headline, for example "Content Credentials found; signer trust not established". |
| A pointer to a record stored online | An XMP key, dcterms:provenance, holding the record's address. | We never fetch it. | "Content Credentials are not available locally". |
| XMP packet | JPEG: APP1 segment. PNG: an iTXt chunk with the keyword XML:com.adobe.xmp, the form the PNG specification recommends. | No. | "Metadata declares AI use" when it carries a generative source type. |
| IPTC-IIM block | JPEG: inside the APP13 Photoshop block. | No. | Credit and source text is read for a tool name, which reads "Tool name found in metadata". |
| EXIF | JPEG: APP1 segment. PNG: an eXIf chunk. | No. | "Tool name found in metadata" when a text tag names an AI tool. |
| PNG text chunks | tEXt, zTXt and iTXt chunks, each with a keyword. | No. | "Tool name found in metadata" when a keyword or its text names a tool. |
Which compartment holds the IPTC source type?
The IPTC Photo Metadata User Guide says Digital Source Type goes only to the XMP structure, not to the older IIM block. Its values come from the IPTC Digital Source Type vocabulary, where the term trainedAlgorithmicMedia carries the label "Created using Generative AI". Our checker reads the XMP property Iptc4xmpExt:DigitalSourceType.
The same vocabulary also appears inside signed records. Among the 31 files we hold other than the C2PA test image, 8 declare an IPTC source type in a record or in the record of an earlier version. Only one holds it as unsigned XMP. The term is shared; the strength depends on the compartment.
What do real files show?
We ran 32 real files through the checker on October 30, 2026, in Chrome. Twenty-nine come from Wikimedia Commons categories named "Images generated by ...", two are vendor samples (one Adobe Firefly, one ChatGPT) and one is the C2PA project's test image. Third parties uploaded the Commons files, so we cannot know how each was handled before upload. These results are about our checker, not about any product.
| Files, by the name they carry | What the file held | Headline |
|---|---|---|
| Adobe Firefly (3), Microsoft Image Creator (2) | A signed record | "Content Credentials found; legacy trust-list match" |
| ChatGPT (1 newer PNG) | A signed record, signer "OpenAI OpCo, LLC" | "Trusted Content Credentials declare AI use" |
| ChatGPT (2 older files) | A signed record whose certificate has expired | "Content Credentials found; signer trust not established" |
| Gemini (1 PNG) | An unsigned XMP packet with a source type | "Metadata declares AI use" |
| Ideogram (1 JPEG) | An EXIF Software tag reading "Ideogram AI" | "Tool name found in metadata" |
| DALL-E (1 PNG) | Two PNG text chunks that hold only dates | "Metadata found; source not established" |
| ChatGPT (1 JPEG) | EXIF dates and a colour profile | "Metadata found; source not established" |
So the same kind of claim sat in different places, each read by a different part of the checker and shown at a different strength. The C2PA test image reads "signer trust not established" too. Nine of the 32 files carry a record. Sixteen read "No supported provenance signals found". The counts are on our accuracy page.
Is a signed record stronger than a label?
For checking, yes. The C2PA explainer (section 7.1.3) says a change to the asset or to the record breaks a cryptographic hash match, so the provenance data is tamper-evident. A label has no signature, so a changed or deleted one looks like an original. A test file we made with only an unsigned XMP source type reads "Metadata declares AI use"; the result says anyone can add or remove it.
Strength is not truth: the explainer (section 2) says Content Credentials give no verdict on whether the data is true. We redrew the 9 real files with a record on a canvas in one browser and saved each as PNG and as JPEG. All 18 outputs read "No supported provenance signals found". That is a canvas test, not a platform.
What do Stable Diffusion tools write into PNG files?
The AUTOMATIC1111 web interface for Stable Diffusion writes its settings into a PNG text chunk with the keyword parameters, when its option to save that information is on. For JPEG and WebP it writes them into the EXIF UserComment tag, according to the source code of its image module. A PNG we drew with one parameters chunk of invented example text reads "Tool name found in metadata". We tested no UserComment file. The real Stable Diffusion PNG in our set has no such chunk.
What does this map leave out?
A watermark is not one of these compartments. Stable Diffusion's reference script applies its invisible mark to the image data itself. We decode that one. We do not check Google's SynthID, Meta's watermark or Adobe TrustMark. Midjourney's help page says every image it delivers has a small ID tag hidden inside the file; it does not say which compartment holds it, and we do not check it.
China's labeling measures (a Chinese-language page), in force since September 1, 2025, say in Article 5 that providers must add implicit labels in the metadata of generated files. We do not map the fields, because we have not read the standard reported to name them (GB 45438-2025). A file we made with field names reported for it reads "Metadata found; source not established", because our checker has no reader for them.
What this means when you check an image
Open the checker, choose the file, and read the headline. "Metadata declares AI use" means an unsigned label in the file says so. "Tool name found in metadata" means a text field names a tool, which is a hint and not a declaration. "Metadata found; source not established" means the file has metadata, but none of it says how the image was made.
None of these proves how the image was made. The result always carries this line: "These checks cannot determine whether an image is AI-generated." A file with nothing, "No supported provenance signals found", is not shown to be real or human-made either.
Guides on this topic
- How to tell if an image is AI
- Content Credentials versus EXIF, IPTC and XMP
- IPTC Digital Source Type values explained
- PNG metadata and Stable Diffusion parameters
- Can EXIF data be faked?
Frequently asked questions
- Where is AI metadata stored in a PNG?
- In text chunks, an XMP packet in an
iTXtchunk, an Exif profile in aneXIfchunk or a signed record in acaBXchunk. A file may hold any of them or none. - Is XMP or EXIF the right place for a source type?
- IPTC's guide sends its Digital Source Type field only to XMP. Neither XMP nor EXIF is signed.
- Can one file hold more than one declaration?
- Yes. In a test file we made, a signed record and an XMP label disagreed. The record headline stayed; the disagreement appeared as a "Conflict" finding.
- Does an empty file mean nothing was declared?
- It means we found nothing. A re-save can drop every compartment, as our canvas test showed.