What Is a C2PA Manifest?
Quick answer: A C2PA Manifest is the structured, cryptographically protected provenance record behind a Content Credential. It can contain claims, assertions, ingredient references, signing information, and applicable asset bindings. Validation results are produced by a verifier; they are not a manifest field that declares itself valid.
C2PA Manifest vs Content Credential
At the data-model level, a C2PA Manifest is the structured, cryptographically protected representation of a Content Credential. In many C2PA documents, a Content Credential is also referred to as a C2PA Manifest.
The two names emphasize different lenses on the same provenance model:
| Term | Most useful emphasis |
|---|---|
| Content Credential | The provenance credential and the name used in user-facing provenance experiences. |
| C2PA Manifest | The technical provenance structure containing claims, assertions, and related signing data. |
So this page should not be read as "a Content Credential contains a manifest." In the C2PA model, the manifest is how the credential is technically represented and processed.
Manifest vs manifest store
At inspection time, C2PA manifests are organized as a manifest store. In a common embedded implementation, that store is carried inside the media file. Implementations may also associate or discover a credential through a sidecar, remote manifest, or another discovery mechanism when that pattern is supported.
The store can include multiple manifests and identifies the active manifest for the asset being inspected. Ingredient manifests can also be present.
ASSET
|
v
MANIFEST STORE
|
+-- ACTIVE MANIFEST
| |-- Claim
| |-- Assertions
| +-- Claim Signature
|
+-- INGREDIENT MANIFESTS
|-- Claim
|-- Assertions
+-- Claim Signature
The active manifest is the manifest associated with the current asset in the store. Ingredient manifests describe source assets referenced during production. Keeping those levels separate prevents a viewer from presenting an old ingredient action as though it were an action applied to the final file.
Core pieces of a manifest
The exact fields depend on the producer, assertion types, file format, and C2PA version, but these are the recurring concepts:
| Piece | What it does |
|---|---|
| Claim | Records information such as the claim generator, asset instance information, and references to assertions. |
| Assertion | Describes a property, event, relationship, or other provenance information. |
| Ingredient | Points to a source asset used to produce the current asset, and may retain its available provenance. |
| Claim signature | Cryptographically protects the signed claim and its protected data. |
| Bindings | Link protected assertions, and where applicable the asset bytes or structure, to the manifest using hashes. |
A claim generator is not necessarily the human author. It is the software or workflow that generated the claim. Likewise, an assertion is not limited to a small fixed list; actions, ingredients, thumbnails, and declared digital source types are common examples.
JUMBF and CBOR packaging
A manifest store is not usually one plaintext JSON file. In supported embedded media formats, C2PA commonly packages the store using JUMBF containers. Core structures such as claims may use CBOR, while particular assertions can use JSON or binary data according to their type.
That is also why ordinary metadata panels often do not show the full credential. A C2PA-aware reader parses the manifest structure and then can present a normalized, human-readable or JSON-like view.
A simplified inspection summary
The shape below is intentionally simplified for explanation. It is not a canonical C2PA JSON schema, the manifest's binary wire format, or a verbatim specification fixture. Fields such as signature_info represent a viewer-normalized summary rather than claiming to reproduce every raw cryptographic structure:
{
"active_manifest": "contentauth:urn:uuid:example-manifest",
"manifests": {
"contentauth:urn:uuid:example-manifest": {
"claim_generator": "Example Editor/1.0",
"format": "image/jpeg",
"instance_id": "xmp.iid:example-instance",
"ingredients": [
{
"title": "camera-original.jpg",
"format": "image/jpeg"
}
],
"assertions": [
{
"label": "c2pa.actions",
"data": {
"actions": [
{
"action": "c2pa.edited",
"softwareAgent": "Example Editor/1.0"
}
]
}
}
],
"signature_info": {
"alg": "ES256",
"issuer": "Example Issuer",
"common_name": "Example Signer"
}
}
}
}
Validation results are separate from the manifest itself. A verifier may report that the structure is well formed, that referenced assertions and hashes match, that the claim signature validates, that an applicable asset binding matches, and whether the signing credential is trusted. That result belongs to verifier output:
Validation results produced by the verifier
Manifest structure: well formed
Claim signature: validated
Asset binding: matched
Signer trust: policy-dependent
How verification reads the manifest
Depending on the asset and validation policy, verification can check manifest structure, hashed references, the applicable asset binding, the claim signature, signer credential validity, timestamps or revocation information, assertions, and ingredient manifests. Not every check applies to every asset.
A valid manifest is not the same as a trusted signer. For the distinction between cryptographic validation and trust, read How C2PA verification works.
Ingredients can carry their own provenance
An ingredient can retain links to provenance information from the referenced source asset when that information is available. A conforming reader may process ingredient manifests so the user can see relevant source history rather than only the final export.
Current asset
|
+-- Ingredient A
|
+-- Ingredient manifest
|
+-- Its own actions,
assertions,
and signature
This is a powerful provenance model, but it is not a guarantee. Whether an ingredient and its manifest are preserved depends on the editing tool, export path, file format, and distribution workflow.
What a manifest does and does not prove
A C2PA Manifest is more than a conventional metadata block: it combines structured provenance assertions with cryptographic signatures and applicable bindings. It can make it possible to inspect what a producer declared and signed.
It does not prove that every claim is factually true, that the depicted scene happened as described, that every edit was recorded, or that the signer should be trusted under every policy. It also does not make absence into evidence: if no readable C2PA Manifest is found, the file may simply come from a workflow that did not attach C2PA provenance, or the credential may no longer be available in a form the viewer can discover.
Inspect a real manifest
Open the C2PA Manifest Viewer to inspect the manifest store, active manifest, ingredient manifests, assertions, signature context, and raw manifest data on your own device. For a plain-language result, use the C2PA Viewer.
Inspect manifest structures locally
Open a file directly in your browser and examine the manifest store, active and ingredient manifests, assertions, signature context, and raw JSON. No file upload is required.
Open C2PA Manifest ViewerOfficial references
For the normative definitions of manifests, claims, assertions, signatures, bindings, and validation, read the official C2PA specifications.
FAQ
Is a C2PA Manifest the same as a Content Credential?
In the C2PA data model, a Content Credential is represented by a C2PA Manifest. "Content Credential" is also used for the broader user-facing provenance experience, while "manifest" is the technical structure a reader processes.
What is the difference between a manifest and a manifest store?
A manifest is one provenance record. A manifest store is the container that can hold the active manifest and ingredient manifests, and it identifies which manifest applies to the current asset.
What is an active manifest?
The active manifest is the manifest associated with the current asset in the manifest store. Other manifests in the store may describe ingredients.
What is an ingredient manifest?
An ingredient manifest describes a source asset used to create the current asset. When it is available, it can expose relevant source provenance separately from actions performed on the final asset.
Can a C2PA Manifest live outside the file?
Yes. C2PA supports embedded manifests and patterns for associated or remotely discovered manifests. Availability depends on the producer, format, binding, and reader support. Soft bindings may also help recover related provenance where implemented.
Does every image have a C2PA Manifest?
No. Many images have no C2PA Manifest. The absence of a readable manifest does not establish that the image is authentic, edited, fake, or AI-generated.
Related guides
Concepts: What are Content Credentials? and C2PA metadata explained. Next: How C2PA verification works or The C2PA Standard.