How do you check a file’s Content Credentials? Locate the C2PA manifest inside the container, recompute the hash of the file bytes outside the manifest and compare it with the hash the signer stored, recompute the hash of every assertion the claim references, and verify the COSE signature over the claim with the public key in the signer’s certificate. If all three agree the file is unchanged since signing and the record is internally consistent; whether the signer is trustworthy is a separate question that needs the C2PA trust list, which this tool does not have, so it shows the certificate chain and says so. A file with no manifest is simply unlabelled: most pipelines strip credentials, and absence proves nothing.
What Does a C2PA Content Credentials Inspector Actually Verify?
A C2PA manifest is a small signed database embedded in a media file. The container (JPEG APP11 segments, a PNG caBX chunk, a RIFF C2PA chunk, an ISO-BMFF uuid box, an ID3 GEOB frame or an SVG <c2pa:manifest> element) carries a JUMBF superbox labelled c2pa; inside it, each manifest holds an assertion store, a CBOR claim and a COSE_Sign1 signature. The claim lists the assertions by hashed URI, names the content-hash assertion that binds the manifest to the file bytes, and is itself the payload of the signature. Verification therefore has three independent, recomputable parts — assertion hashes, content hash and signature — and one part that needs outside data: whether the signing certificate chains to a trusted C2PA participant. This tool performs the first three and is explicit that it skips the fourth. The structure follows the C2PA Technical Specification, v2.4 (accessed Oct 2026), ISO/IEC 19566-5 JUMBF (2019) for the box format and RFC 9052 COSE (Aug 2022) for the signature.
What this can and cannot tell you
It can tell you
- Whether a manifest is present, how many manifests are chained (ingredients), and which is active.
- Whether the file bytes are unchanged since signing (content hash) and whether every assertion is the one the signer referenced.
- Whether the signature verifies against the certificate the signer supplied, and that certificate’s subject, issuer, serial, validity and algorithms.
- What the signer declared: software, actions with timestamps,
digitalSourceType(for example trainedAlgorithmicMedia), ingredients, authors and AI training/mining preferences. - Whether an RFC 3161 timestamp is attached, its time and TSA, and whether it binds to this signature.
- Whether XMP still references a manifest that is no longer there (probably stripped) or lives at a remote URL.
It cannot tell you
- Whether the signer is who the certificate says, or is a recognised C2PA participant — that needs the C2PA trust list, which is not bundled; a self-signed test certificate verifies just as cleanly.
- Whether the content is true or not AI-generated. Credentials describe how a file was made as the signer declared it; a valid AI-disclosure credential is honest labelling, and a missing credential is not evidence of anything.
- Whether a certificate has been revoked (no OCSP/CRL fetch).
- Anything about files whose credentials were stripped, beyond the fact that they were.
- Fragmented BMFF (Merkle) hashes, PDF, GIF and TIFF/DNG manifests — detected but not verified here.
Checks at a glance
| Check | What is recomputed | Result labels | Limit |
|---|---|---|---|
| Manifest location | Container walked box by box; JPEG APP11 packets reassembled by box-instance and sequence number; ISO-BMFF uuid matched on the C2PA UUID; sidecar .c2pa accepted | embedded · sidecar · remote reference · probably stripped · none · container not parsed | Multiple stores: only the first is parsed |
| Assertion hashes | SHA-256/384/512 of each referenced assertion superbox (description box + content) compared with the claim’s hashed-URI | match · mismatch · missing · external | Redacted assertions are listed, not recomputed |
| Content hash | c2pa.hash.data: file bytes minus the declared exclusions. c2pa.hash.bmff v1–v3: boxes matched by xpath (with data/subset/flags rules) removed; for v2+ each kept top-level box is preceded by its 8-byte offset, as the reference implementation does | match · mismatch (altered after signing) · absent · unsupported · not applicable (earlier manifests) | Merkle-tree fragmented BMFF not verified |
| COSE signature | WebCrypto verify over Sig_structure = ["Signature1", protected, "", claim] using the leaf certificate’s SPKI; ES256/384/512 (P-256/384/521), PS256/384/512 (RSA-PSS, salt = hash length), RS256; Ed25519 if the browser exposes it | valid · invalid · unverifiable in this browser · error | Ed25519 support varies by browser (checked at run time) |
| Certificate chain | DER parsed: subject/issuer (CN, O, OU, C), serial, notBefore/notAfter, key and signature algorithm OIDs, SAN, EKU, key usage; chain order checked issuer→subject and AKID→SKID | expired flag · order ok / broken · self-signed root | Not checked against the C2PA trust list; no revocation lookup |
| Timestamp | RFC 3161 token from sigTst/sigTst2 parsed for genTime, policy, TSA; message imprint recomputed over the countersignature structure | present + bound · present but not bound · absent | TSA certificate trust not evaluated |
How does the inspector read a manifest?
Every byte string is decoded by code written for this page: a CBOR decoder for the claim and assertions (major types 0–7, indefinite lengths and tags per RFC 8949 (Dec 2020)), a JUMBF walker for superboxes, description boxes, labels, UUIDs and salts, a DER parser for X.509 certificates and the RFC 3161 (Aug 2001) timestamp, and a COSE_Sign1 reader that accepts the certificate chain in the protected header (C2PA 2.x) or the unprotected header (1.x). Hashes use WebCrypto digest and signatures WebCrypto verify; no library is downloaded. The manifest tree view shows the raw box structure so that a second examiner can confirm what was parsed.
Why does the verdict say “signer not checked against trust list”?
C2PA validators decide whether a signer is a known participant by matching the certificate chain against a trust list distributed to validators. Without that list a clean signature only proves that whoever holds the private key for the shown certificate signed this claim; the test fixtures used to build this tool, signed with throwaway certificates, verify perfectly. The reference inspector at contentcredentials.org/verify (Content Credentials) applies the trust list; use it when the signer’s identity matters. For how C2PA fits alongside AI detectors and watermarks, see the AI provenance & C2PA hub.
What does “probably stripped” or “remote reference” mean?
When a signer writes a manifest it also writes dcterms:provenance into the file’s XMP, pointing at the manifest. Many exports, resizers and platform uploads drop the JUMBF segment but keep XMP, leaving that pointer orphaned; the inspector reports this as probably stripped. The pointer can also be a URL: C2PA allows the manifest store to live on a server (Adobe’s cloud-signed exports do this). The tool never fetches it on its own; a button offers to request that one URL, and says so, because that request leaves your browser. Everything else, including the file itself, stays local.
Test method
The parser was compared field by field with the open-source c2pa-rs reference reader (contentauth, 2026) on its public test assets (claim v1 JPEGs with ingredients, a JPEG whose ingredient has a deliberately broken signature, a remote-manifest JPEG and a two-manifest MP4), on PNG, WebP, AVIF, HEIC, MP4, MP3, WAV and SVG files signed for the test with ES256, ES384, ES512, PS256, PS384, PS512 and Ed25519 (claim v2), on files with no credentials, and on a copy with one byte flipped outside the manifest. Manifest labels, claim fields, assertion data, ingredients, signer details and timestamp times matched the reference on every fixture; the flipped byte produced the hash-mismatch verdict and the broken signature was reported invalid. The digitalSourceType values shown follow the IPTC Digital Source Type vocabulary (IPTC). For pixel-level checks that do not depend on metadata, use the Photo Forensics Studio or Video Forensics Studio; for the rest of the metadata, the EXIF viewer; for the workflow, the image forensics guide.