Content Credentials explained: detected, valid, trusted and unverified
“Content Credentials found” and “trusted Content Credentials” are not the same result.
That distinction matters whenever you are checking an image before sharing it, describing it with an AI assistant or relying on it as evidence. A verifier may find a C2PA manifest, validate its cryptographic bindings and still be unable to establish that the signer belongs to the trust framework it uses.
The safest way to read a provenance result is to ask two questions:
- What was found in this file?
- What, exactly, was verified?
What are Content Credentials?
Content Credentials are a user-facing name for provenance information carried using the C2PA standard. A credential can record claims about an asset’s origin, edits, tools, ingredients and signing information. When a compatible tool records an AI-generation action, the credential may preserve that information as part of the asset’s history.^1
A credential is not the same thing as ordinary camera metadata. EXIF fields such as a camera model, capture time or GPS coordinates are useful evidence, but they are not automatically signed. Content Credentials are designed to bind claims to an asset through cryptographic mechanisms.
That still does not make them a universal real-or-fake detector. They describe the claims and evidence available in the file. They do not guarantee that every earlier event in an image’s history was recorded.
Detected: a credential is present
Detected means that the verifier found a readable Content Credential or C2PA manifest in the file.
It is a useful starting point, but it is not the strongest conclusion. Presence alone does not tell you whether:
- the signature is valid;
- the file still matches the signed asset;
- the signer is trusted by this verifier; or
- the credential describes the complete history.
A result that says “detected” should therefore be read as: “This file contains a provenance structure that can be examined further.” It should not be paraphrased as “This image is authentic.”
Valid: the cryptographic checks passed
Valid means the credential’s relevant cryptographic checks and asset bindings passed validation.
In plain English, the verifier was able to check that the signed information is consistent with the file and that the signature operation itself passed. This is stronger than simple presence.
However, a valid signature does not automatically mean the signer is trusted. A real organisation, camera or software vendor may be outside the particular trust list configured by the verifier. The result can therefore be:
Valid, but signer untrusted.
That is not the same as invalid. It means the cryptographic evidence passed, while the verifier could not connect the signer to its configured trust policy.
Trusted: the signer passed the configured trust policy
Trusted means the credential validated and the signer also passed the verifier’s configured trust policy or trust anchors.
This is a policy decision as well as a cryptographic result. A verifier needs to know which certificate authorities, organisations or signing identities it is prepared to trust. The official browser C2PA library supports explicit verification contexts and trust-anchor configuration rather than treating every valid signature as trusted.^2
A trusted result is therefore best read as:
“This credential is valid, and its signer is trusted under this verifier’s configured policy.”
It is not a guarantee that the visual content is true, that the creator’s claims are complete or that no unrecorded changes happened before the signed history began.
Invalid: a check failed
Invalid means that one or more required checks failed. Depending on the file and the verifier, the problem may involve a signature, a hash, an asset binding or another required part of the manifest.
An invalid result is important evidence that the credential should not be relied on as a valid signed history for this copy of the file. It still does not explain every possible cause. A damaged download, an altered file or an incomplete transfer can all affect validation.
Treat an invalid result as a reason to preserve the original file, check the source and avoid presenting the credential as trustworthy.
Not found and unverified: absence is not a verdict
Not found means that no readable Content Credential was found in the particular copy you inspected.
That can happen because:
- the image was created without Content Credentials;
- the tool that exported it did not preserve them;
- a messaging platform or editor stripped them;
- the file is a screenshot or re-save; or
- the credential is present in a format the verifier does not support.
Missing credentials do not prove that an image is fake or human-made. They simply mean that this copy does not provide that particular provenance signal.^3
Unverified is a broader description. It may mean that a credential was detected but could not be connected to a trusted signer, or that the available information is insufficient for the verifier’s policy. It should not be collapsed into “false”.
A simple way to read the labels
| Result | What it tells you | What it does not tell you |
|---|---|---|
| Detected | A readable credential is present | That the signature or signer is trusted |
| Valid | Cryptographic and asset-binding checks passed | That the signer is trusted or the history is complete |
| Trusted | Valid evidence passed the configured trust policy | That every visual claim is true or every prior event was recorded |
| Invalid | A required validation check failed | The exact cause without further investigation |
| Not found | No readable credential was found in this copy | That the image is fake or human-made |
How MUTANT Inspect presents the distinction
MUTANT Inspect keeps these states separate because a single green tick hides too much. It checks the selected image locally in the browser, reports the available credential state and explains the limits around that result.
It also reports ordinary image metadata separately. A file can have GPS or camera metadata without Content Credentials. A file can have Content Credentials without readable camera metadata. These are different evidence layers and should not be treated as interchangeable.
Inspect an image locally with MUTANT Inspect.
For a step-by-step explanation of the workflow, see How to use MUTANT Inspect.
The practical rule
When you see a provenance result, do not ask only, “Is it green?” Ask:
- Was a credential detected?
- Did the cryptographic checks pass?
- Did the signer pass this verifier’s trust policy?
- Is the result about this exact file copy?
- What information is still missing?
That vocabulary makes provenance more useful because it preserves uncertainty instead of disguising it.