How C2PA Verification Works
Verification is more than one check
C2PA verification is the everyday name for several related checks. A reader may validate manifest structure, local references and hashes, the asset binding, the claim signature, signing credential validity, timestamps or revocation, and finally trust. The exact work depends on the credential, asset type, reader, and validation policy.
C2PA validation produces evidence and status codes, not a universal truth score.
That is why a viewer can report a valid structure but an untrusted signer, or a well-formed manifest whose asset binding no longer matches. Collapsing those outcomes into one green mark loses useful evidence.
Validation layers
The C2PA model separates concerns so a reader can report what passed or failed:
C2PA VALIDATION
1. Structure
|
2. References & hashes
|
3. Asset binding
|
4. Claim signature
|
5. Credential validity
|
6. Timestamp / revocation
|
7. Trust evaluation| Layer | What a reader may check |
|---|---|
| Structure | Required manifest structures are present and well formed. |
| References and hashes | Referenced assertions are present locally, and their recorded hashes match. |
| Asset binding | Applicable hard bindings still match the asset bytes or asset structure. |
| Claim signature | The signature validates and protected claim data has not changed in a way the signature detects. |
| Credential validity | The signing credential and certificate chain satisfy the applicable credential checks. |
| Timestamp / revocation | Cryptographic timestamp tokens and revocation information, when present, satisfy the reader's validation policy. |
| Trust evaluation | The signing credential is recognized under the reader's configured trust anchors or trust list. |
The diagram is conceptual, not a fixed sequence for every file. Some checks may be informational, unavailable, policy-dependent, or omitted when a credential does not use the corresponding mechanism.
Signatures and asset binding
The claim signature cryptographically covers the signed provenance record. Cryptographic bindings link that record to relevant assertions and, where applicable, to asset bytes or asset structure. C2PA can use data hashes, BMFF hashes for suitable media structures, or other hard-binding mechanisms.
For manifest-internal references, a reader checks that the referenced assertions are packaged locally and that their recorded hashes match. This is container-internal validation, not an HTTP request to resolve a URL.
If protected claim data, an assertion, or the bound portion of the media no longer matches, validation can report that mismatch. The signature does not make a claim true. It helps establish who signed the claim and whether the protected data still validates under the applicable checks.
Valid vs Trusted
These words answer different questions:
| Result | Meaning |
|---|---|
| Valid | The manifest and applicable cryptographic validation checks passed. |
| Trusted | The manifest is valid and the signing credential is trusted by the verifier's trust context. |
A self-signed credential can be cryptographically valid but untrusted in a given reader. A manufacturer-signed credential can also stop being valid if its asset binding fails. Neither word is a shorthand for authentic.
In C2PA Lab, Trusted and Valid SDK states are both surfaced as Verified, with the signature context shown separately. Valid appears with a signer-not-recognized context; Invalid appears as Verification failed; an undetermined state appears as Verification unavailable.
Trust lists and policy
C2PA uses certificates and trust anchors. A verifier considers whether a signing credential chains to a trust list or locally configured anchor. Trust lists and reader configurations can change over time, and revocation information may also be time-sensitive.
A trust decision is therefore contextual. The same credential can produce different trust results in two readers with different trust configurations. A verifier may treat an unknown signer differently from a signer recognized by its configured trust anchors or trust list.
Why verification fails
Verification and validation are related but not identical. Signature verification is one layer of validation; a C2PA reader may also validate structure, bindings, credentials, timestamps, revocation, and trust. This page keeps verification in headings because that is the term people use when checking a file, while validation is useful for the broader set of checks.
Common causes include a modified manifest, changed asset bytes, a hash mismatch, a signature that does not validate, an invalid or unrecognized signing credential, or a timestamp or revocation check that cannot be completed. The exact status code depends on the file, reader, and SDK version.
| Status code | What the reader found | What it can mean |
|---|---|---|
assertion.dataHash.mismatch | A recorded data hash no longer matches. | The covered asset data changed, was re-encoded, or the applicable exclusions and hash context do not match. |
assertion.hashedURI.mismatch | A manifest-local hashed reference does not match its target. | The expected assertion is missing, changed, or damaged inside the manifest structure. |
claimSignature.mismatch | The claim signature did not validate. | Protected claim data or signature material changed, was damaged, or cannot be validated by this reader. |
signingCredential.untrusted | The signing credential is not trusted. | The signature context may be cryptographically valid, but the signer is outside the reader's trust policy. |
These examples come from C2PA Lab's current bundled SDK. They are not an exhaustive standard-wide list, and a conforming implementation may surface additional informational, success, or failure codes.
A verification failure is evidence that the credential or its binding did not validate. It is not automatically proof of malicious manipulation; an export bug or unsupported feature can also produce a failure.
What a verified result proves
A verified result says that the reader found a readable credential and that its applicable checks succeeded under that reader's policy and configuration. It gives you named evidence to inspect: the signer and signature context, recorded actions, ingredients, source declarations, assertions, and validation status.
That evidence can be strong context for deciding how much to trust an asset. It is not, by itself, a final fact-check of the real world.
What a verified result does not prove
A successful verification does not prove that every claim in the credential is true. It does not prove the scene happened as described, that every edit was recorded, or that the signer is trustworthy under your policy. It shows that the credential and its asset binding remained verifiable under the checks performed.
Likewise, no credentials does not mean AI-generated, edited, or fake. It means the viewer did not find a readable C2PA provenance record in the inspected asset. It does not rule out a sidecar, remote manifest, unsupported packaging, or a reader-specific discovery mechanism.
Check a real file
Open the C2PA Viewer and inspect a file locally. For signed manifest structure and raw validation data, use the C2PA Manifest Viewer. For the normative rules, read the official C2PA specifications.
Check validation evidence locally
Open a file directly in your browser and review the credential status, signature context, actions, ingredients, validation issues, and raw manifest data. Your file stays on your device.
Check a fileOfficial references
FAQ
Does a verified C2PA file prove the image is authentic?
No. Verification shows that the credential and applicable bindings passed the verifier's checks. It does not prove that every recorded claim is true or that the scene happened as described.
What is the difference between Valid and Trusted?
Valid concerns manifest structure and cryptographic validation. Trusted additionally depends on whether the verifier's trust configuration recognizes the signing credential.
Why can editing a photo break C2PA verification?
Many edits change the bytes covered by a hard binding. A new manifest can record the edit and refer to the original as an ingredient, but preserving and discovering those credentials depends on the tool, export path, and publisher.
Does a missing credential mean the file is fake?
No. Absence only means no readable C2PA credential was found in the inspected asset. It says nothing by itself about whether the file is authentic, edited, or AI-generated.
Why might another viewer report Trusted while C2PA Lab does not?
Trust is policy-dependent. Readers can use different trust lists, anchors, versions, revocation settings, or validation policies. Compare the signature, validation codes, and trust context rather than treating one label as universal.
Related guides
Background: What is a C2PA manifest? and How to check C2PA Content Credentials.