The idea in one paragraph
Content Credentials are a signed record travelling inside an image file that says where the image came from and what has been done to it since. The record is created by whichever tool produced or edited the file, hashed against the pixels, and signed with a certificate. Anyone can read it. Anyone with a verifier can check that the signature is intact and that the pixels have not changed since it was applied.
The specification behind it is C2PA, from the Coalition for Content Provenance and Authenticity. A joint effort of Adobe, Microsoft, Arm, Intel, the BBC, Truepic and others, now with OpenAI, Google, Sony, Nikon, Leica and Canon involved. "Content Credentials" is the user-facing name for the same thing.
What is inside a manifest
A C2PA manifest is a small structured document embedded in the file. It contains four things that matter to a reader.
| Part | Contents | Example |
|---|---|---|
| Claim generator | The software that wrote the manifest | Adobe Firefly 1.0 c2pa-rs/0.28.2 |
| Assertions | Statements about the asset: origin, actions, ingredients, thumbnails | c2pa.actions, stds.iptc |
| Hard binding | A cryptographic hash of the image data | Ties the claim to these exact pixels |
| Signature | A COSE signature over the claim, plus the signing certificate | ES256, PS256, Ed25519 |
The actions list is the most readable part. It uses a fixed vocabulary, so you get a short history rather than a paragraph of marketing copy.
| Action | Meaning |
|---|---|
c2pa.created |
This asset was newly created by the claim generator |
c2pa.edited |
The asset was modified |
c2pa.placed |
Another asset was placed into this one |
c2pa.cropped, c2pa.resized, c2pa.color_adjustments |
Specific edits |
c2pa.converted, c2pa.transcoded, c2pa.repackaged |
Format changes |
c2pa.opened |
An existing asset was opened as the starting point |
An image generated by DALL·E and then retouched in Photoshop can carry both manifests: the Photoshop manifest references the earlier one as an ingredient, so the chain stays readable. That chaining is the real point of the standard, not a single yes/no flag, but a lineage.
Where the manifest physically lives
The manifest is wrapped in a JUMBF container (JPEG Universal Metadata Box Format) and then placed wherever the file format allows arbitrary boxes.
| Format | Location |
|---|---|
| JPEG | APP11 marker segments, split across segments if large |
| PNG | A caBX chunk |
| WebP | A C2PA RIFF chunk |
| AVIF, HEIC, MP4 | A jumb box in the ISO base media container |
| TIFF, DNG | A dedicated tag |
Because it is a normal metadata box, it is subject to the normal fate of metadata: anything that re-encodes the file without C2PA support drops it. That includes most social platforms, most screenshot tools and most quick "save for web" exports. See why Instagram strips image metadata.
What SynthCheck shows you, and what it does not
Drop a file into SynthCheck and it answers four questions, separately, in your browser:
- Is the signature valid? The COSE signature over the claim is verified against the public key in the certificate.
- Does it cover this image? The hard binding is recomputed from your file's bytes. This is the check that catches a manifest lifted off a genuinely signed photograph and stapled onto a different one, and it is the one a naive reader skips.
- Does the certificate chain hold together? Each certificate is verified against the one above it, and each issuer must actually be entitled to issue: declared a certificate authority, permitted to sign certificates, and within its path length limit. Verifying the links alone is not enough. The authorities on the list sell ordinary signing certificates to customers, so "signed by the certificate above it" without "and that certificate was allowed to sign it" lets anyone holding one certificate mint others in any name they like.
- Does the chain end somewhere anybody vouched for? The top of the chain is matched against the C2PA Conformance Program's published list of authorities allowed to issue signing certificates. Matched by verifying a signature, not by reading a name: a certificate that simply types "DigiCert" into its issuer field does not pass.
Each of those is reported as its own line, because each fails on its own and a single green tick covering all four would hide the interesting cases.
Two things it still does not do, and neither can be fixed in a browser that refuses to send your file anywhere. Revocation: a certificate withdrawn after it was issued still reads as valid here, because finding out means asking somebody's server. Time-stamp validation: an expired certificate is flagged as expired on the card, but a signature made while it was live cannot be told apart from one backdated afterwards without a trusted time-stamp authority. contentcredentials.org/verify covers both, if you need them and are willing to upload the image to get them.
The wider workflow is in how to check if an image is AI-generated.
Hard bindings, soft bindings and durable credentials
A hard binding is the hash. Change one pixel and it stops matching, which is exactly what you want for tamper-evidence, and exactly what makes the credential fragile: a legitimate re-compression also breaks it.
Because of that fragility, the ecosystem is layering in soft bindings, invisible watermarks and perceptual fingerprints that survive re-encoding. Adobe calls the combination "durable" Content Credentials: metadata for the detail, a watermark to signal that a credential once existed, and a fingerprint to look the original manifest up in a cloud registry after the metadata has been stripped.
This is promising and not yet universal. Today, if the metadata is gone, the credential is gone for most practical purposes.
What a credential does and does not prove
| Claim | Supported? |
|---|---|
| "This tool wrote this manifest" | Yes, if the signature validates against a trusted issuer |
| "These pixels match the ones the claim covers" | Yes, via the hard binding |
| "This image is AI-generated" | Yes, if the manifest says so, generators declare it |
| "This image is NOT AI-generated" | No. A missing credential says nothing at all |
| "This photograph depicts a real event" | No. A signed camera capture proves capture, not truth about the subject |
That fourth row is the one to internalise. Absence of a Content Credential is not evidence of authenticity. Metadata is trivially stripped, most images in circulation have never had a credential in the first place, and screenshots start life with a completely clean slate.
How this connects to the law
Article 50 of the EU AI Act requires providers of generative AI to mark synthetic output in a machine-readable form, applying from 2 August 2026, with penalties up to EUR 15,000,000 or 3% of worldwide annual turnover. Systems placed on the market before that date have until 2 December 2026 for the marking obligation.
The regulation does not name C2PA. It asks for marking that is "effective, interoperable, robust and reliable as far as technically feasible". C2PA is the obvious candidate because it already exists, is cross-vendor, and is machine-readable by design, but IPTC DigitalSourceType tags and invisible watermarking are also on the table. More in EU AI Act Article 50 and image labelling.
FAQ
Can Content Credentials be faked? The manifest contents can be written by anyone, but a valid signature cannot be forged without the private key. That is why signature validation matters: an unverified manifest is an assertion, a verified one is an attributed assertion. Note also that a signature proves who signed, not that what they signed is true.
If I crop an image, do I lose the credential? In a C2PA-aware editor, no. The tool writes a new manifest recording the crop and referencing the original as an ingredient. In a tool with no C2PA support, usually yes: the metadata block is discarded and the chain ends there.
Do cameras write Content Credentials? Some do. Leica, Sony, Nikon and Canon have shipped or announced in-camera Content Credentials on specific bodies, usually as an opt-in setting. Coverage is still small compared with the number of cameras in use.
Does a Content Credential tell me if an image was generated with SynthID-watermarked models? Only if the manifest happens to mention it. SynthID is a pixel watermark, not metadata, and reading it needs Google's own model. The Gemini app will do it for you, see SynthID explained, and its limits. The two systems solve different halves of the problem and are meant to be used together.