The C2PA standard: what it specifies, who runs it, and what a check really tells you

Short answer: The C2PA standard is an open, royalty-free technical specification for attaching a signed provenance record (a "manifest") to images, video, audio and documents. It is written by the Coalition for Content Provenance and Authenticity, a Joint Development Foundation project. "Content Credentials" is the name for those records. The standard can prove a record is intact and who signed it, not that the content is true.

Most explanations stop at "it's like a nutrition label for media". This one covers the parts that decide what a C2PA result actually means for you: the three validation states, the trust list, the conformance program, and what the specification deliberately leaves out.

Who writes the standard

C2PA was announced on 22 February 2021 by Adobe, Arm, the BBC, Intel, Microsoft and Truepic. It merged two earlier efforts: the Adobe-led Content Authenticity Initiative (CAI) and Project Origin, led by Microsoft and the BBC. A public draft went out for comment in September 2021, and version 1.0 of the technical specification was released in January 2022.

Three names get used interchangeably, and they are not the same thing:

The C2PA's own FAQ says no license fees are required and that the specification is released as an open standard under a royalty-free license. The documents are public at spec.c2pa.org, and the specification has moved through a 2.x series since 2.0. Each version carries a version-history section listing what changed, so check that page rather than trusting any article's claim about "the latest version", including this one.

What the specification defines

The core technical specification is not a single idea but a set of definitions that have to fit together. The main pieces, using the spec's own terms:

• Assertion: a single statement made by the signer, such as which tool created the asset, which actions were performed, or that the content came from a trained model.
• Claim: a digitally signed, tamper-evident structure that references a set of assertions about an asset.
• Manifest: the provenance information built from those assertions plus the claim and its signature.
• Manifest store: a collection of manifests, which can be embedded in the file or kept externally. The last one is the "active" manifest.
• Ingredients: earlier assets that went into this one, each of which may have its own manifest.
• Hard binding: a cryptographic hash of the asset (or specific byte ranges or boxes of it) so that any change to the covered content is detectable.
• Soft binding: a looser identifier, like a fingerprint or invisible watermark, that is not statistically unique but can help find a manifest again.
• Time-stamps: the spec encourages signing tools to get a time-stamp from an RFC 3161 time-stamp authority so that a manifest stays valid after the signing certificate expires.

The specification also defines how each file format holds a manifest store, how validators find it, and what error codes they report. If you want to see where the bytes physically sit in a JPEG, PNG, MP4 or WebP, that's covered in our Content Credentials explainer.

The three validation states

This is the part most guides skip, and it is what a "verified" badge actually rests on. The specification defines manifest states that build on each other:

1. Well-formed: the manifest follows the specification's structural rules. It parses, and the required parts are present.
2. Valid: well-formed, and the claim signature checks out cryptographically. Nothing covered by the signature has been altered since signing.
3. Trusted: valid, and the signing certificate chains to a certificate authority that the validator trusts.

There is also a valid asset: the hard bindings show the covered content is unmodified and the active manifest is valid or trusted.

The gap between valid and trusted matters. Anyone can generate a certificate and sign a perfectly valid manifest. It will verify mathematically, but a validator using the official trust list won't show it as trusted, because nobody vouched for the signer. When you see a Content Credential, the useful question is which of these states the tool is reporting.

The trust list and the conformance program

"Trusted" needs a list of who counts, and the C2PA now runs that list itself.

• The C2PA Trust List is a curated list of certificate authorities. Validators use it to decide whether a signer is trusted.
• The Conformance Program, opened in June 2025, evaluates three kinds of participants: generator products (tools that create manifests), validator products (tools that read and check them) and certificate authorities. A conforming generator must sign with an X.509 certificate from a CA on the trust list. Approved products appear on a public conforming products list.
• Assurance levels: the program currently has two, level 1 and level 2. The level is written into the signing certificate as an extension, so a validator can tell how strong the product's security architecture was judged to be.
• The Interim Trust List (ITL) was a stop-gap from the early-adoption period. The C2PA's own documentation describes it as superseded by the official trust list and says it was frozen on 1 January 2026, with no new entries or updates. Content signed with ITL certificates can still validate in tools that use the ITL, but may be flagged as relying on older trust roots.

The practical effect is that two validators can show different results for the same file, depending on which trust lists they load. That isn't a bug in either one.

What the standard deliberately doesn't do

Some of these are design choices written into the documents, not oversights:

• It doesn't judge content. The specification's scope quotes the C2PA guiding principles: it should not make value judgments about whether a given set of provenance data is "good" or "bad". A manifest that says "generated by an AI model" is a statement of origin, not a verdict.
• It doesn't identify people by default. The FAQ says the core specification does not support attributing content to individuals or organisations, for privacy reasons. Version 2.0 removed identified humans from assertion metadata and removed the actors field from the actions assertion. Identity claims now come from separate extensions that some communities are building on top.
• It isn't DRM. The FAQ is explicit: Content Credentials do not control what you can do with a file.
• It can't verify what it can't see. If an ingredient's own data isn't available, a validator can only confirm that the earlier step was validated by whoever made the composite, not re-check it.

Limits: what a C2PA check can't tell you

Here's the honest part, including about our own tools.

A missing manifest proves nothing. The specification tells validators to look for an embedded manifest store, then for a remote one, and to report an error if a referenced remote manifest can't be reached. It can't say a file should have had one. Re-encoding a file from its pixels drops the manifest (this is why canvas exports strip C2PA). Many platforms re-encode uploads, and most cameras don't sign at all. A file with no Content Credentials looks just like one that never had them.

Soft bindings are the standard's answer to stripping, and they're partial. A watermark or fingerprint can help find the manifest in an external repository after the metadata is gone. That only works if someone registered the manifest there and the watermark survived. And fingerprints aren't unique by definition, so a match is a lead, not proof.

Valid is not true. A signed manifest proves the record is intact and names the certificate behind it. A real camera pointed at a staged scene still produces a valid, trusted manifest.

Our checker only detects presence. The content credentials checker runs in your browser and scans the file for C2PA markers (the JUMBF box and labels such as c2pa.claim and c2pa.signature). It tells you whether a manifest is there. It does not check signatures, so it can't tell you whether a manifest is well-formed, valid or trusted. For that, use a validator that implements the spec, such as the open-source c2patool:

c2patool your_image.jpg

Removing a manifest removes one signal, not all of them. The C2PA remover re-encodes images in your browser, which drops C2PA along with EXIF, XMP and IPTC. JPEG output is re-encoded at quality 0.95, so the pixels are not bit-identical to the original. It doesn't touch pixel-level watermarks, platform classifiers or what you disclose when you post. Instagram's label, for example, can come from more than metadata (see how the AI info label works). Stripping metadata doesn't make you anonymous either: the platform still logs who uploaded what.

Questions people ask

Is the C2PA standard an ISO standard? The documents are published by the C2PA itself at spec.c2pa.org. Check the C2PA's own announcements for any formal ISO status rather than relying on secondary sources.

Does C2PA detect AI images? No. It records what the signing tool says happened. If an AI generator signs its output and the manifest survives, a validator can show that. It doesn't analyse pixels.

Is it free to implement? Yes, according to the C2PA: royalty-free, no license fees. Getting onto the trust list as a generator is a separate step that goes through the conformance program and a certificate authority.

Can a camera sign offline? Yes. The FAQ notes that offline devices can sign with locally stored keys.

The short version

The C2PA standard defines a signed, tamper-evident record that travels with a file, plus the rules to validate it. Read any result by its state: well-formed, valid or trusted. A trusted manifest tells you who signed what and that it's unchanged. It doesn't tell you the content is true, and a missing manifest tells you nothing at all.