C2PA is a standard for attaching a signed, tamper-evident record of an image's origin and edit history to the file itself. The name belongs to the Coalition for Content Provenance and Authenticity, the industry group that writes the spec. Content Credentials is the consumer-facing name for the same thing, usually shown as a small "CR" pin. The difference from EXIF is the signature: a C2PA record is cryptographically bound to the exact bytes of the image, so edits made outside a C2PA-aware tool show up as a broken credential instead of going unnoticed.
It does not prove a picture is true. It proves who signed which claims about it.
Who is behind the standard
C2PA was formed on February 22, 2021 by Adobe, Arm, BBC, Intel, Microsoft and Truepic, as a project of the Joint Development Foundation. It merged two earlier efforts: Adobe's Content Authenticity Initiative (CAI) and Project Origin, led by Microsoft and the BBC. The Content Credentials site now lists Google, Meta, OpenAI, Sony and Amazon among the companies leading it.
The specification is public on c2pa.org. The CAI maintains the open-source SDKs and the c2patool command-line tool, documented at opensource.contentauthenticity.org.
What a manifest contains
A file carries a manifest store, which holds one or more manifests. The last one is the active manifest. Earlier ones document history, for example the camera's original manifest kept as an ingredient after an edit in Photoshop.
Each manifest has four parts:
- Assertions, the actual statements.
c2pa.actionslists what happened (c2pa.created,c2pa.opened,c2pa.edited,c2pa.resizedand so on). Ingredient assertions point to the source files an image was made from, with their own manifests. Thumbnails and selected metadata can be added too. - A hard binding: a hash of the asset's bytes, typically SHA-256, computed over everything except the manifest itself. For a JPEG this is usually the
c2pa.hash.dataassertion. A standard manifest has exactly one. - The claim, which lists every assertion by hashed reference and names the software that produced it.
- The claim signature: a COSE structure signed with an X.509 certificate, optionally countersigned by a timestamp authority.
A validator recomputes the hashes, checks the signature, then checks whether the certificate chains to a trust list such as the C2PA Trust List. A manifest can be cryptographically valid yet signed by nobody the validator trusts. Anyone can sign a manifest with a self-made certificate; it just won't show up as trusted.
For AI generators, the spec says the first action must be c2pa.created with a digital source type. Two lines from its own example:
"action": "c2pa.created",
"digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia",That is what "C2PA metadata says this is AI" means in practice: a signed action whose source type is trainedAlgorithmicMedia.
Where the manifest is stored in the file
The manifest store is serialized as JUMBF, the JPEG Universal Metadata Box Format (ISO/IEC 19566-5). Each format wraps it differently:
| Format | Where the manifest lives |
|---|---|
| JPEG | APP11 segments, several in a row if over 64 KB |
| PNG | A caBX chunk, recommended before IDAT |
| WebP | A C2PA chunk at the end of the RIFF container |
The spec also covers TIFF, GIF, JPEG XL, ISO BMFF formats and others, plus manifests stored outside the file: a .c2pa sidecar, or a remote manifest whose URL is referenced from XMP (dcterms:provenance).
ExifTool recognizes the block but does not validate it. On a test JPEG I built with a minimal manifest-store box in APP11 (headers only, no real claim or signature):
$ exiftool -G1 -a -s -JUMBF:all stub.jpg
[JUMBF] JUMDType : (c2pa)-0011-0010-800000aa00389b71
[JUMBF] JUMDLabel : c2paA JUMBF box labeled c2pa means a manifest store is present. Whether it is valid is a separate question.
How to inspect Content Credentials
The quickest route is the Verify site at contentcredentials.org/verify. Drop a file and it shows the signer, the date, the recorded actions and the ingredient chain, with a warning when validation fails.
For scripting, use c2patool:
c2patool photo.jpg
c2patool photo.jpg --info
c2patool photo.jpg -d
c2patool photo.jpg --treeThe first prints the manifest store as JSON. --info gives a short report with the manifest count and whether it validated, -d the detailed low-level structure, --tree a tree of assertions and ingredients.
The EXIF reader here does not parse C2PA. It does show the IPTC DigitalSourceType field when a file has one, which some generators write alongside a manifest.
Who embeds Content Credentials
Only claims the vendors make on their own pages, as of October 2026:
- OpenAI's help center says images generated with ChatGPT, Codex and the OpenAI API carry C2PA metadata, plus an invisible SynthID watermark.
- Adobe applies Content Credentials automatically to assets where 100% of the pixels were generated with Firefly, including through Firefly APIs. Photoshop and Lightroom can attach them to ordinary edits if you turn the feature on.
- Leica announced the M11-P in October 2023 as the first camera to attach Content Credentials at capture, signing in dedicated hardware.
- Meta says it reads the "AI generated" information in C2PA and IPTC metadata to apply its "AI info" label on Facebook, Instagram and Threads.
The list grows every few months. Check the vendor's own documentation rather than third-party roundups.
How it relates to IPTC DigitalSourceType
The source type URIs are not the coalition's own invention. They come from IPTC's Digital Source Type vocabulary at cv.iptc.org, which also has digitalCapture for camera originals, compositeWithTrainedAlgorithmicMedia for generative edits such as inpainting, and others.
The same URI can sit in plain XMP as XMP-iptcExt:DigitalSourceType, outside any manifest:
[XMP-iptcExt] DigitalSourceType : http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMediaSome generators write both. The difference matters: the XMP field is an unsigned label that anyone can add, change or delete, while the C2PA action is signed. See Digital Source Type for the full list of values.
Removing C2PA: what it does and what it doesn't
A manifest is metadata, and removing it is trivial. exiftool -all= drops APP11 in JPEG, caBX in PNG and the C2PA chunk in WebP; I checked all three on test files with ExifTool 12.76. To remove only the manifest and keep EXIF and XMP, use exiftool -JUMBF:all= photo.jpg. The metadata remover runs a full -all=, so it removes the manifest along with everything else, including any IPTC DigitalSourceType.
Editing a signed file in a tool that doesn't understand Content Credentials is a different outcome. ExifTool, for example, keeps the APP11 segments when you change a tag, but the bytes covered by the hard binding have changed, so validators reject the manifest (assertion.dataHash.mismatch in the spec's terms). You end up with a credential that says "something changed after signing".
What stripping does not do:
- It does not touch invisible watermarks. Google DeepMind describes SynthID as embedded in the pixels and designed to survive cropping, filters and lossy compression. OpenAI images carry it too. No metadata tool, ours included, removes it.
- It does not delete copies held elsewhere. Adobe stores Firefly manifests in its Content Credentials cloud and says they can be recovered if stripped from the file, and the spec defines watermark and fingerprint "soft bindings" for exactly that lookup.
- It does not make an image "not AI". A stripped file is a file with no provenance, which is the state of most real photos on the web too. Absence of credentials proves nothing in either direction.
There are legitimate reasons to strip: a manifest can carry your name, your edit history and thumbnails of the ingredient images, and you may not want to publish those. Just don't mistake removing the label for changing what the image is.