What is a C2PA Manifest?
Disclaimer: This article is an independent educational guide based on publicly available C2PA specifications. C2PA Viewer is not affiliated with the C2PA coalition or its member organizations.
TL;DR — C2PA Manifest in 60 seconds
- What it is: A cryptographically signed data structure embedded inside a digital file recording its full provenance.
- Also called: Content Credential — the consumer-facing brand name used by Adobe, Google, and others.
- Core components: One or more assertions + one claim + one claim signature.
- Container format: JUMBF (JPEG Universal Metadata Box Format); assertions serialized as CBOR; signature uses COSE.
- Tamper detection: A hard binding cryptographic hash ties the manifest to the exact file bytes — any pixel-level edit breaks the hash.
The Short Answer: What a C2PA Manifest Is
A C2PA manifest is a digitally signed, tamper-evident data structure that stores the provenance record of a digital file. According to the C2PA Technical Specification v2.2 (published May 2025), a manifest contains three required components: one or more assertions (statements about the content), a single claim (a digest of all assertions), and a claim signature (a cryptographic signature over the claim using a trusted certificate). The manifest is stored inside the file in a JUMBF container or as a separate sidecar file.
The manifest is also known as a Content Credential — the consumer brand name promoted by the Content Authenticity Initiative (CAI) and used in product labeling by Adobe, Google, and other members. The underlying technical object is identical regardless of which name is used.
The Three Core Components
Every C2PA manifest has exactly three logical layers. Understanding them is key to understanding what a verification tool actually checks.
| Component | What it contains | Serialization |
|---|---|---|
| Assertions | Individual factual statements: actions taken, ingredients used, creator identity, AI usage, etc. | CBOR, JSON-LD, XML, or binary depending on assertion type |
| Claim | A manifest summary: SHA-256 hashes of all assertions, a hard binding hash of the file content, and the claim generator identity | CBOR |
| Claim Signature | A cryptographic signature over the claim bytes, plus the signer's X.509 certificate chain for verification | COSE_Sign1 (RFC 9052) |
Assertion Types: What Can a Manifest Record?
Assertions are the payload of a C2PA manifest — the actual statements about the content. The specification defines several standard assertion labels; third parties can also register custom assertions. The most commonly used standard assertions are:
| Assertion label | What it records | Typical source |
|---|---|---|
| c2pa.actions | Ordered list of editing operations (crop, color correction, AI inpainting, export, etc.) with timestamps | Photo/video editor |
| c2pa.ingredient | A source file (image, audio, video) used to create the current file, referenced by its own manifest hash | Compositing tool |
| c2pa.hash.data | Hard binding: SHA-256 hash of the media bytes the manifest covers — verifying this proves the file has not been pixel-edited since signing | Any signing tool |
| stds.schema-org.CreativeWork | Creator name, organization, social handles, and website — expressed as Schema.org JSON-LD | Creative software or identity provider |
| c2pa.exif | Camera make/model, lens, GPS location, shutter speed, ISO — signed EXIF data that cannot be silently edited | Camera hardware |
| c2pa.ai_generative_training | Creator's explicit declaration on whether the content may be used for AI training | Creator or rights holder |
| c2pa.thumbnail.claim.jpeg | A small preview image embedded in the manifest for display in credential UI overlays | Any signing tool |
How the Hard Binding Works
The hard binding is the mechanism that ties the manifest to the specific file bytes it covers. Without it, an attacker could take a legitimate manifest from an authentic photo and attach it to a manipulated one.
The C2PA specification defines the hard binding as a SHA-256 hash over a defined byte range of the media file — typically all bytes except the JUMBF region that stores the manifest itself. This hash is recorded inside the claim. When a verifier reads the file, it recomputes the hash over the same byte range and compares it to the stored value. If even a single pixel has changed, the hash will not match and verification fails.
For streaming formats (video, audio), the specification defines a soft binding approach using content hashes over individual media segments, allowing partial verification of large files without loading the entire file into memory.
The Manifest Store and Provenance Chain
A file may contain a manifest store — a collection of multiple manifests, one per editing step. Each manifest in the store is identified by a unique label. The active manifest (the most recent edit) references previous manifests via the c2pa.ingredient assertion, forming a provenance chain.
Example: Provenance chain for an edited news photograph
- Manifest 1 — Camera (Sony Alpha): Records capture timestamp, GPS location, camera settings, and hard binding hash of RAW file. Signed by Sony's C2PA certificate.
- Manifest 2 — RAW developer (Adobe Lightroom): References Manifest 1 as ingredient. Adds c2pa.actions for exposure adjustment and export to JPEG. Signed by Adobe.
- Manifest 3 — News wire (Reuters): References Manifest 2. Adds metadata assertion with journalist attribution and publication identifier. Signed by Reuters' certificate.
Each signer's private key is independent. Breaking one signature does not break others — but any broken signature is reported during verification.
Storage: Where Does the Manifest Live?
The C2PA specification defines three storage methods, suited to different use cases.
| Method | How it works | Best for |
|---|---|---|
| Embedded | JUMBF box written inside the file container (JPEG APP11, MP4/MOV metadata box, PDF stream) | Photos, videos, PDFs — file stays self-contained |
| Sidecar | Manifest stored in a separate .c2pa file alongside the media file, linked by filename convention | Formats that cannot carry embedded metadata (e.g., some RAW formats) |
| Remote | File carries only a URL reference; manifest fetched on demand from a Content Credentials cloud service | Large video files, streaming scenarios, or size-constrained environments |
How Verification Works
A C2PA verifier performs the following steps in order. Any failure at any step means the manifest cannot be trusted for that specific check.
- Parse the JUMBF container and extract the manifest store from the file bytes.
- Identify the active manifest by its label (the most recently signed one).
- Validate the claim signature using the embedded X.509 certificate chain. The chain must lead to a trusted root recognized by the C2PA Trust List.
- Check certificate status. The verifier confirms no certificate in the chain has been revoked (via OCSP or CRL) and that the signing time is within the certificate's validity period.
- Verify assertion hashes. The claim contains SHA-256 hashes of each assertion. The verifier recomputes these hashes from the raw assertion bytes and compares them to the claim.
- Verify the hard binding. The verifier computes the SHA-256 hash of the media byte range specified in the claim and compares it to the stored hard binding hash.
- Recursively verify ingredients. For any c2pa.ingredient assertions, the verifier validates the referenced ingredient manifests using the same process.
This entire process can run offline. All required data — assertions, claim, signature, and certificate chain — travels inside the file. No external API call is needed unless the manifest uses remote storage or includes OCSP/CRL check URLs.
Privacy Controls in Manifests
C2PA provides several mechanisms for creators who want provenance without unwanted data disclosure.
- Optional assertions: GPS location, device serial number, and creator identity are never required. Creators choose exactly which assertions to include.
- Assertion redaction: An assertion can be removed from the manifest after signing. The claim records a redaction entry (a hash tombstone) in place of the removed assertion, preserving the chain of trust without exposing the original data.
- Selective disclosure: The C2PA specification supports selective disclosure patterns where individual fields within an assertion can be omitted without invalidating the signature on the remaining fields.
- Anonymized signing: Signers can use a pseudonymous certificate that identifies their organization without exposing personal identity — useful for journalists working in sensitive contexts.
AI-Generated Content and Manifests
AI-generated content disclosure is one of the fastest-growing uses of C2PA manifests. When an AI platform creates an image, it can embed a manifest asserting the generation method and model. Standard assertions for AI content include:
- c2pa.actions with action c2pa.created and digitalSourceType set to trainedAlgorithmicMedia — indicating fully AI-generated content.
- c2pa.actions with digitalSourceType set to compositeWithTrainedAlgorithmicMedia — indicating AI-assisted editing of a real photograph.
- c2pa.ai_generative_training — creator's explicit consent or refusal for training use.
Adobe Firefly, Stability AI, and OpenAI DALL-E all embed C2PA manifests with AI generation assertions on supported outputs, as of 2025.
Frequently Asked Questions
What is a C2PA manifest?
A C2PA manifest is a digitally signed data structure embedded inside a media file that records the file's provenance: who created it, when, what tools were used, whether AI was involved, and every significant edit since creation. It is also called a Content Credential.
What is the difference between a C2PA manifest and a Content Credential?
They are the same thing. 'Content Credential' is the consumer-friendly brand name used by the CAI and C2PA members; 'C2PA manifest' is the technical specification term. Both refer to the same signed provenance data structure.
What is a C2PA assertion?
An assertion is a single statement inside a C2PA manifest about one aspect of the content — for example, editing actions performed, ingredients used, creator identity, or AI generation disclosure. Multiple assertions are collected into a claim, which is then signed.
What file format does a C2PA manifest use?
A C2PA manifest is stored in a JUMBF container. Most assertions are serialized as CBOR (RFC 7049) for compactness. The claim signature uses COSE (RFC 9052). Some assertion types use JSON-LD or XML.
Can a C2PA manifest be faked?
A valid C2PA signature cannot be forged without access to the signer's private key. An attacker could create a new manifest with a key they control, so the C2PA Trust List — a registry of approved signers — is critical: verifiers check whether the signing certificate belongs to a recognized, non-revoked entity.
What happens to a C2PA manifest when a file is edited?
A C2PA-enabled editing tool creates a new manifest for the output file. The new manifest references the previous manifest via a cryptographic hash and lists the editing actions performed. This creates a chain of manifests — a provenance trail — from original capture through every editing step, each with its own independent signature.
Explore a Real C2PA Manifest
Upload any C2PA-signed image, video, or PDF to the C2PA Viewer. The tool parses the JUMBF container, displays every assertion, and reports the full verification result — including hard binding status, certificate details, and provenance chain.
Open Manifest Analyzer →