Content Credentials (C2PA) Inspector
Content Credentials (C2PA) are signed provenance records embedded in images, video, audio and documents by cameras, editors and AI generators. Drop a file to read them with c2pa-rs, the C2PA reference implementation, running in your browser as WebAssembly: the manifest chain, actions, ingredients and validation results are shown, and the file is never uploaded.
The file is read in this browser tab by the C2PA reader (WebAssembly from this site); it is never uploaded, and remote manifests are not fetched.
Image, video or audio file
Drop an image, video or audio file here, or
JPEG, PNG, WebP, AVIF, HEIC, TIFF, GIF, SVG, MP4, MOV, WAV, MP3, PDF and more — up to 1 GB.
Trust anchors (optional)
Whether a signer is trusted depends on a trust list. Content Credentials apps use the C2PA trust list of conforming products; this page bundles none, so intact credentials are “not trusted” until you add the roots you rely on. Certificates only; URLs are not fetched and private keys are refused.
Examples
Test images of c2pa-rs (C.jpg and CA.jpg from its test fixtures, MIT or Apache-2.0) and its test roots “C2PA Test Root CA — FOR TESTING ONLY”, loaded as trust anchors where the example needs them. The changed example flips one bit of the image data in your browser.
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.