What Is C2PA? Content Credentials Explained

The short version

C2PA — the Coalition for Content Provenance and Authenticity — is a specification for attaching a signed record of provenance to a file. The record travels inside the file, and it answers three questions:

• Who says so? A signing certificate, checked against a list of trusted issuers.
• What was done? A list of declared actions: created, cropped, resized, colour-adjusted, combined with another file.
• Is this the same file? A hash of the asset, recorded at signing time.

Adobe, Microsoft, Google, the BBC and a group of camera makers back it. The consumer-facing name is Content Credentials, and the small "CR" pin you may have seen on images is the C2PA logo.

The important part is what it is not: it is not a truth serum, and it is not a watermark.

A manifest is a small document, not a tag

Most metadata is a flat list of fields. A C2PA manifest is a structure:

manifest store
├── manifest (the active one)
│   ├── claim generator      "Adobe Photoshop 25.3"
│   ├── claim                the hash of every assertion, signed together
│   ├── assertions
│   │   ├── c2pa.actions     created / cropped / colour_adjustments
│   │   ├── c2pa.hash.data   the asset hash (the hard binding)
│   │   ├── c2pa.thumbnail
│   │   └── digitalSourceType  trainedAlgorithmicMedia, digitalCapture, …
│   └── signature            the certificate and the signature over the claim
└── ingredient manifests     one per source file, when files are combined

The whole store is CBOR wrapped in a JUMBF box — an ISO-standard container that can live inside JPEG, PNG, WebP, MP4, PDF and others without changing the media data.

Two consequences follow from that structure. A file can carry several manifests (each tool that signs appends one, forming an edit chain), and each manifest can carry ingredients, each with its own hash and its own manifest. That is how a composite image can show what it was built from.

Verification happens in three layers

A verifier that only reads the manifest is just reading text anyone could write. Real verification checks three things in order, and each can fail independently:

1. Hard binding. The manifest records a hash of the asset. If the pixels changed after signing — a crop, a re-save, a metadata stripper — this hash no longer matches, and everything downstream is void.
2. Signature. The claim (a hash of all the assertions) is signed with a private key. The verifier checks it against the public key in the certificate stored in the file.
3. Trust. The certificate has to chain to a certificate authority on a trust list. C2PA publishes one; a verifier can also keep its own.

Layer 3 is where most confusion lives. A signature can be perfectly valid and the file perfectly intact while the certificate is unknown — because the tool that signed never enrolled, or because it is a test build. That is a different outcome from a broken signature, and a verifier that shows both as "fake" is wrong.

That three-layer check is exactly what our C2PA viewer runs, in the browser, against the public trust list.

What a manifest can prove

• These bytes are the bytes that were signed. A hash mismatch is strong evidence the file was edited after signing.
• The claim was signed by whoever holds that certificate. Certificates identify organisations, not people.
• What the signing tool chose to declare. That includes the generator, the action list and the digital source type.

What it cannot prove

• That the content is true. A camera can photograph a staged scene; a generator can sign an honest record of generating something.
• That the file was never changed before signing. Only edits after signing break the hash.
• That a person made it. Certificates belong to organisations and devices.
• That the absence of a manifest means anything. Most files in the world have none.

Why most files have none

Provenance only exists if every tool in the chain writes it, and only survives if the last one keeps it:

• Most cameras do not sign. A few models from Leica, Sony and Nikon do.
• Many editors strip it silently, because they rebuild the file on export.
• Every social platform re-encodes uploads and drops the manifest with the rest of the metadata.
• Screenshots, screen recordings and messaging apps produce files with no provenance at all.

So an empty result is the normal case, not a suspicious one. Our viewer says "no C2PA signature found" and then shows the ordinary metadata evidence next to it, because that is all that can honestly be said.

Removing it

A manifest is metadata: it lives in a container box beside the media data, and it can be removed without touching a single pixel or frame. That is what the C2PA remover does, and the file still plays and displays exactly as before.

Whether you should is a separate question. Removing provenance to protect privacy — a client's file name, a location, a device identity — is ordinary metadata hygiene. Removing it to pass AI-generated media off as a photograph is deception, and the tool will not help you claim otherwise: it reports what was there before it removed it.

Removing a manifest does not remove an invisible watermark. SynthID and similar systems encode a mark in the pixels themselves; no metadata tool can touch them, and any tool promising otherwise is guessing.

The honest summary

C2PA gives you one narrow, useful guarantee: this file is the file that was signed, by the holder of that certificate, and here is what the signer said about it. Everything beyond that — truth, intent, authorship by a human — is outside what a signature can carry.

Read the manifest, check the signature, look at the trust chain, and then decide for yourself. That is what the numbers are for.