Content Credentials (C2PA) Inspector — inspecteur de manifestes C2PA

What Content Credentials are

Content Credentials are the C2PA standard's signed provenance records (C2PA specification 2.x). A camera, an editor or an AI generator that supports them embeds a manifest in the file — in a JUMBF box of a JPEG or PNG, a box of an MP4 or HEIC, a chunk of a WAV. A manifest holds assertions (what was done: actions, ingredients, the author, training and mining preferences, a thumbnail), a claim that lists the hashes of those assertions and binds them to the file's content, and a COSE signature over the claim with an X.509 certificate of the signer. Every edit by a C2PA-aware tool adds a new manifest that names the previous file as an ingredient, so a file can carry a whole chain of provenance.

Credentials prove who signed which claims and that nothing changed since. They do not prove the claims are true: a signer can lie, and the value of a manifest is the value of its signer.

How the file is read

The inspector does not reimplement the standard. It runs c2pa-rs, the C2PA reference implementation, compiled to WebAssembly (@contentauth/c2pa-web, MIT) in a Web Worker of this page. The reader — about 9 MB — is downloaded from this site the first time you inspect a file and is not part of the page otherwise. It validates exactly what the specification requires:

• Hard binding — the hash of the file's content outside the manifest. If a single pixel or audio sample changed after signing, the binding no longer matches and the file is reported as changed.
• Assertions — every assertion's hash against the claim, so edited or removed assertions are caught.
• Claim signature — the COSE signature over the claim, the signing certificate's profile and validity, and an embedded RFC 3161 time-stamp, if present.
• Ingredients — the manifests of earlier versions embedded in the file, with their own signatures.

The page turns the reader's validation codes into checks and keeps the codes themselves under Validation codes, with the reader's explanations.

Trusted, valid, not valid

C2PA distinguishes a manifest that is well-formed and intact from one whose signer is trusted. Trust needs a trust list: Content Credentials apps use the C2PA conformance program's list of products and certificate authorities. The inspector bundles none and fetches none, so an intact manifest is reported as intact, but the signer is not trusted until you paste the roots you rely on under Trust anchors. The examples load the c2pa-rs test roots this way. A manifest whose content, assertions or signature fail is not valid, whatever its signer.

Reading the AI labels

Actions and ingredients may carry an IPTC digital source type. The inspector summarises the whole chain: trainedAlgorithmicMedia on the creation action of the latest manifest means created by generative AI; compositeWithTrainedAlgorithmicMedia, or a generative source anywhere else in the chain, means generative AI was used; algorithmicMedia and similar codes mean created or changed by an algorithm that is not trained AI. Captured and human-made sources raise no label. The label repeats what the signed manifest states — it is not a detector, and a file without credentials says nothing either way. Training and mining preferences (c2pa.training-mining) are listed as the creator set them.

What stays on your device

The file is read with the File API and processed in this tab; it is never uploaded. Two features of C2PA readers would contact other servers, and both are switched off: remote manifests, credentials stored at a URL named in the file, are reported but not fetched, and OCSP revocation checks of the signing certificate are not made. Either request would tell a server which file you are looking at. The preview of your image and the stored thumbnail are shown from local object URLs.

Social networks and messengers often strip metadata when they re-encode an upload, credentials included. If an image you expected to be signed shows none, look for the original file. Certificates inside the manifests can be read in full in the certificate decoder, and signed time-stamps in the time-stamp inspector.