A Content Credential is useful only if a validator can connect it to the content it is supposed to describe. That sounds like one problem, but digital provenance actually has two different association problems. The first is exact: does this manifest belong to this protected asset representation, and have the covered bytes or structures changed? The second is resilient: can related provenance still be found after a platform has resized, transcoded, recompressed, printed, scanned, or stripped metadata from the content?
C2PA addresses the first problem with hard bindings and the second with soft bindings. A hard binding is a cryptographic commitment to a specific protected representation. A soft binding is a content-derived matching signal that can help identify renditions or recover a detached manifest after the underlying bits have changed. They are complementary mechanisms, not interchangeable substitutes.[1]
Two binding types, two different questions
The easiest way to understand C2PA bindings is to separate integrity from durability. Hard bindings make changes to protected content detectable. Soft bindings make provenance easier to rediscover after ordinary distribution systems have broken the original byte-for-byte association.
Question | Hard binding | Soft binding |
|---|---|---|
Primary purpose | Exact association and tamper evidence | Matching, discovery, and recovery |
What it operates on | The protected bytes or format structures of an asset | Features or identifiers derived from, or embedded in, the perceptual content |
Expected match behavior | A match should identify this protected representation, not a rendition | A match may identify the same content across renditions or transformations |
Typical technologies | Cryptographic hashes with format-specific coverage rules | Perceptual fingerprints and invisible watermarks |
Manifest role | Required in a standard manifest; exactly one supported hard-binding assertion | Optional; a manifest may contain zero or more soft-binding assertions |
Result to present | The manifest validates against the current asset representation | One or more candidate manifests may be related to the observed content |
A standard C2PA manifest contains exactly one supported hard-binding assertion. It may also contain any number of soft-binding assertions. An update manifest is the important exception: because it adds restricted provenance information without changing the protected content, it contains no new hard binding and instead points back through a parent relationship to the earlier manifest whose hard binding remains authoritative.[2]
Hard bindings: exact cryptographic association
A hard binding commits the signed manifest to a defined representation of the asset. During validation, the verifier calculates the required hash or hashes from the asset it has received and compares them with the values recorded in the hard-binding assertion. A match supports two related conclusions: the manifest belongs with that protected representation, and the content covered by the binding has not changed since the claim was signed.
The word exact needs one qualification. A hard binding is exact within its declared coverage rules. An embedded manifest cannot ordinarily hash itself, and some file formats require specific regions or structural boxes to be excluded. If a byte or box is outside the binding scope, a change to that excluded area may not affect validation. The binding is therefore a cryptographic statement about protected content, not a magical guarantee about every possible property of the file.
A valid hard binding can help establish | A valid hard binding does not establish by itself |
|---|---|
This manifest is associated with this protected asset representation. | The depicted event is real or the assertions are factually accurate. |
The content covered by the binding has not changed since signing. | The provenance history is complete. |
A substituted manifest that does not match the asset should be detected. | The signer is trusted for the reader's purpose. |
The validator applied the format-specific binding rules successfully. | Excluded or unprotected regions have not changed. |
The claim signature protects the hard-binding assertion through the claim's hashed reference to that assertion. This creates a chain of integrity: the signature protects the claim, the claim protects the binding assertion, and the binding assertion commits to the asset. Trust in the signer and interpretation of the provenance statements remain separate decisions.
Why the manifest cannot simply hash the entire file
When a Manifest Store is embedded inside an asset, hashing the entire finished file would create a circular dependency. The manifest contains the hard-binding value and the claim signature, but inserting those values changes the file that would have been hashed. C2PA resolves this by defining format-aware ways to omit the Manifest Store or other necessary regions from the binding calculation while protecting the rest of the relevant asset structure.
A typical signing sequence is therefore:
1. Complete all content-affecting transformations, including any invisible watermarking intended to become part of the final content.
2. Prepare the final container layout and the location where the Manifest Store or reference will be placed.
3. Calculate the applicable hard binding using the required exclusions or box rules.
4. Place the binding assertion in the claim, sign the claim, and write the completed Manifest Store.
5. Independently validate the final output to confirm that the hard binding and signature still succeed.
Exclusions should be as narrow as the format and workflow permit. Excluding an area means allowing that area to change without necessarily breaking the hard binding. C2PA guidance favors format-aware exclusion models over broad byte-range approaches when the format supports them, and recommends including ordinary asset metadata such as EXIF or XMP in the binding where practical. Covering that metadata protects its integrity; it does not automatically make the signer responsible for the truth of the metadata unless it is also included as a created assertion.
The hard-binding methods in C2PA 2.4
C2PA does not force every media type into one generic hash layout. The specification defines several hard-binding assertion types so the binding can follow the structure of the asset format.
Assertion | Typical use | Core approach |
|---|---|---|
c2pa.hash.data | Generic assets and unstructured text when no better format-aware method applies | Hashes asset bytes while declaring the ranges that must be excluded. |
c2pa.hash.boxes | Non-BMFF box or marker formats such as JPEG, PNG, TIFF, and GIF | Hashes named structural boxes or groups of boxes in their file order. |
c2pa.hash.bmff.v3 | ISO BMFF formats such as MP4, fragmented MP4, HEIF, and AVIF | Uses BMFF box structure, exclusions, offsets, and optional Merkle data for segmented or large media. |
c2pa.hash.collection.data | Collections of files or logical assets, including datasets and archive-like workflows | Records hashes for the members identified by URI and, where applicable, collection structure. |
Data hashes and byte-range exclusions
The data hash assertion is the most general hard-binding form. It hashes the relevant bytes of an asset while identifying exclusion ranges, such as the space occupied by an embedded Manifest Store. This flexibility allows it to work with formats that have no C2PA-aware structural model, but it also places more responsibility on the implementation to calculate offsets correctly and avoid excluding content that can affect what a person sees or hears.
C2PA implementation guidance recommends SHA-256 when a workflow has no reason to choose another permitted algorithm. It also recommends using a more format-aware box binding instead of a general byte-range binding whenever the asset format supports one, because structural models can reduce classes of coverage and insertion errors.
General box hashes
Many image and container formats are organized into identifiable boxes, segments, or markers. A general box hash assertion lists the relevant structures in file order and records hashes over their data. This lets the binding account for the asset's organization rather than treating the file as an undifferentiated byte stream.
The validator must understand the format well enough to locate the boxes safely and apply any required special handling. A box-aware binding is not simply more convenient syntax; it is part of the security model because it helps prevent unprotected content from being inserted into structurally meaningful locations.
BMFF hashes for image and video containers
ISO Base Media File Format assets, including common video and image containers, receive a dedicated hard-binding design. The current assertion label is c2pa.hash.bmff.v3. The model uses the BMFF box hierarchy and exclusion rules, and can include Merkle information for fragmented or progressively processed media. This allows validators to handle large media and independent segments without abandoning cryptographic coverage of the overall asset structure.
The exclusion list is security-sensitive. A box should not be excluded if modifying it can change the audio-visual presentation or alter external content the workflow intends to make tamper-evident. Older BMFF assertion versions may still appear in historical assets, but new implementations should use the current non-deprecated version supported by C2PA 2.4.
Text, collections, and multi-part assets
Unstructured text with an embedded C2PA wrapper uses the data hash model with text-specific normalization and exclusion rules. Collections use the collection data hash assertion to bind a set of members rather than one monolithic byte stream. This can be useful for archives, training-data collections, or other logical assets whose integrity depends on several files.
C2PA also defines a multi-asset hash assertion for files whose individual parts may need separate verification, such as a media asset with an auxiliary gain map. Despite its name, that assertion is not itself the one required hard binding. It supplements the ordinary hard binding by describing and validating the parts.[3]
What causes a hard-binding validation failure?
Any change to protected content can break an exact binding, even when the change is harmless or visually subtle. Common examples include:
- resizing, cropping, filtering, or recompressing an image;
- transcoding video or audio, changing codecs, or remuxing covered container structures;
- editing covered EXIF, XMP, document metadata, or text;
- normalizing line endings or Unicode representation in a way not accounted for by the applicable text rules;
- reordering or inserting covered boxes or segments;
- using a valid manifest from a different asset; and
- writing additional content after signing when that content falls within the protected scope.
A mismatch does not prove malicious tampering. It proves that the manifest's protected representation does not match the representation being validated. The change may have come from a routine social-media rendition, a document conversion, or an authorized edit performed by a non-C2PA-aware tool. A C2PA-aware transformation should normally issue a new standard manifest with a new hard binding and preserve the earlier asset as provenance.
Credential absence is a different state from credential mismatch. If the Manifest Store was stripped, there may be no hard binding available to validate at all. Soft bindings exist largely to help in that missing or decoupled-manifest scenario.
Soft bindings: resilient matching after the bytes change
A soft binding operates through the digital content of an asset rather than requiring an exact sequence of bytes. C2PA recognizes two broad families: fingerprints computed from content and invisible watermarks embedded into content. Both can support matching after transformations that would invalidate an ordinary hard binding, such as resizing, recompression, transcoding, or container changes.
A soft binding is recorded in a c2pa.soft-binding assertion. The assertion identifies the algorithm, carries one or more algorithm-specific values, and can describe the region or time span over which the binding was calculated. C2PA maintains a Soft Binding Algorithm List so implementations can refer to algorithms using stable identifiers and understand whether an entry represents a fingerprint or watermark and which media types it supports. C2PA does not define the matching quality, robustness threshold, or security properties of every listed technology; those remain algorithm-specific.
A manifest can contain more than one soft binding, for example a watermark identifier plus a perceptual fingerprint. Multiple signals can improve recovery and help check whether a watermark has been transferred to unrelated content. None of them replaces the standard manifest's hard binding.[4]
Fingerprints and invisible watermarks
Characteristic | Fingerprint | Invisible watermark |
|---|---|---|
How it is created | Computed from the content without intentionally changing it | Inserted into the perceptual content before final signing |
What is matched | A content-derived descriptor or feature representation | An embedded identifier or signal extracted from the content |
Typical lookup | Compute the query asset's fingerprint and search for near or exact algorithm-specific matches | Extract the watermark payload and use it as a repository lookup key |
Main strength | Can provide a fallback even when no watermark was inserted | Can carry a stable identifier that survives many expected transformations |
Main risk | False matches, missed matches, and adversarial manipulation of the similarity model | Removal, corruption, detection failure, or transfer of the watermark to unrelated content |
Effect on asset bytes | No intentional change from fingerprint computation | Changes the content and therefore must be applied before the final hard binding |
For watermark-based durable provenance, the watermarking operation should be recorded in the manifest. C2PA guidance requires a c2pa.watermarked.bound action when an invisible watermark is inserted for soft-binding purposes, together with the corresponding soft-binding assertion that identifies the algorithm and binding value. Because inserting the watermark changes the content, watermarking belongs before the hard-binding calculation and claim signature in the production pipeline.
Fingerprint matching usually returns a similarity result rather than a universal yes-or-no answer. The threshold, feature representation, resistance to adversarial examples, and behavior across crops or edits depend on the chosen algorithm. A platform should not hide those differences behind one generic "soft binding valid" status.
How soft-binding recovery works
Soft bindings become most useful when the Manifest Store is copied to a manifest repository and associated with the binding value. A typical recovery flow is:
1. The publisher computes a fingerprint or inserts an invisible watermark and records the soft-binding assertion.
2. If watermarking changed the content, the publisher calculates the hard binding only after the watermark is present.
3. The completed Manifest Store is signed, embedded when appropriate, and also ingested into a repository.
4. A downstream platform creates a rendition or removes the embedded Manifest Store.
5. A consumer computes a fingerprint or extracts the watermark from the observed content.
6. A resolver queries one or more repositories and receives zero, one, or several matching active-manifest identifiers.
7. The consumer retrieves candidate Manifest Stores, verifies their signatures and internal integrity, and presents the relationship with appropriate qualifications.
The C2PA Soft Binding Resolution API standardizes this exchange. It supports queries using a supplied binding value, uploaded content, or a content reference; separate routes retrieve manifests, store manifests, associate bindings, and expose service capabilities. The API standardizes interoperability around discovery and repository operations, not the accuracy of an individual matching algorithm.[6]
A soft match is not the same as manifest validation
The most important implementation rule is to keep recovery and validation separate. Suppose a social platform resizes an image and removes its embedded Manifest Store. A watermark may still lead a resolver to the original manifest. The original manifest can be cryptographically valid as a signed object, but its hard binding will usually not validate against the resized rendition because the bytes and possibly the dimensions have changed.
The safe interpretation is that the recovered manifest is candidate provenance associated with related content. Additional evidence - a matching fingerprint, a thumbnail, a known publication context, a later C2PA manifest for the rendition, or human review - may strengthen that relationship. It should not be silently upgraded into an exact hard-binding result.
Observed result | Responsible interpretation |
|---|---|
Embedded manifest found and hard binding matches | The manifest is cryptographically bound to this protected representation, subject to the remaining signature and trust checks. |
Manifest found but hard binding mismatches | The manifest does not validate against the current representation; investigate transformation, corruption, or substitution. |
One soft-binding match returns a candidate manifest | The observed content may be related to the candidate; verify the manifest and present the match type and confidence. |
Several soft-binding matches are returned | The result is ambiguous; do not select one silently. Use additional signals or human review. |
No soft-binding match is returned | No repository match was found. This does not prove the content is false, unsigned, or unrelated to all provenance. |
Local manifest and recovered candidate disagree | Treat the discrepancy as a reason for investigation, not automatic proof that either source is correct. |
Security, privacy, and operational tradeoffs
Matching errors and adversarial manipulation
Soft bindings are deliberately tolerant, which means they cannot provide the same uniqueness guarantee as a cryptographic hard binding. Similar but unrelated content may collide under a fingerprint. An attacker may try to manipulate content so that it moves toward or away from a target representation. Watermarks can be degraded, erased, or copied from one asset to another. Combining independent signals can help, but it does not turn an approximate match into an exact one.
Lookup privacy and linkability
A resolver query can reveal that a person or organization is examining particular content. Uploading an asset to a remote service exposes even more information. C2PA guidance therefore recommends informed, opt-in lookup behavior and notes that computing the soft binding on the client can reduce the need to transmit the full asset. Implementers should also consider whether a persistent watermark identifier can be used to track distribution or reconnect content with information a creator expected to remain redacted.
Repository availability and lifecycle
A soft binding is only useful for recovery if a repository still holds the Manifest Store, the binding association remains intact, and a resolver knows where and how to query it. Retention, deletion, regional deployment, access control, rate limits, denial-of-service protection, algorithm deprecation, and service continuity are therefore part of the provenance design. A durable signal without durable infrastructure is not durable provenance.[5]
Choosing a binding strategy
Every production C2PA system needs the hard-binding path. The decision is how much additional durability the workflow requires and which soft-binding technology is appropriate for its media, audience, privacy model, and distribution environment.
Workflow | Recommended pattern | Reasoning |
|---|---|---|
Controlled archive or internal DAM | Format-aware hard binding, redundant Manifest Store preservation, and periodic validation | The organization controls transformations and may not need public soft-binding lookup. |
Public images distributed through social platforms | Embedded hard-bound manifest plus repository copy and watermark or fingerprint | Metadata stripping and resizing are likely, so recovery matters. |
Video streaming and syndication | New hard binding for each C2PA-aware rendition plus durable watermarking and repository resolution | Transcoding and repackaging routinely break exact file bindings. |
Generative media API | Hard-bind each final output, record AI disclosures, and optionally add a durable identifier before signing | The output needs exact provenance at creation and may later leave the provider's infrastructure. |
Sensitive or private content | Hard binding with carefully scoped private resolution, explicit consent, and limited retention | Public lookup or persistent identifiers may create unacceptable privacy risk. |
There is no universally best soft-binding algorithm. The right choice depends on transformations to survive, acceptable false-match rates, perceptual-quality constraints, computational cost, supported media types, whether identifiers may be externally resolved, and how the lookup service handles privacy and abuse.
A practical example: a news image
Consider a publisher preparing a licensed news photograph for broad online distribution.
1. The editor completes the crop, tonal adjustments, and final export settings.
2. The publisher inserts an invisible watermark carrying a repository identifier and records the watermarking action.
3. The publisher optionally computes a perceptual fingerprint and includes both soft-binding signals in the active manifest.
4. The system calculates the hard binding over the final watermarked image, signs the claim, embeds the Manifest Store, and stores a copy in the repository.
5. A social platform strips metadata, recompresses the image, and serves a smaller rendition. The original hard binding no longer validates against that rendition, and the embedded manifest is gone.
6. A viewer extracts the watermark, resolves the candidate manifest, compares the available fingerprint or thumbnail, and displays the provenance as recovered from a soft binding rather than as an exact hard-bound validation of the rendition.
If the platform itself were C2PA-aware, it could instead create a new standard manifest for the rendition. That new manifest would hard-bind the transformed image and preserve the publisher's earlier manifest as ingredient provenance. Soft recovery is most valuable when that complete handoff did not occur.
Designing reliable implementations
For claim generators and signing services
- Apply all content-affecting operations, including invisible watermark insertion, before calculating the hard binding.
- Use the format-specific hard-binding assertion recommended for the asset rather than defaulting to broad byte exclusions.
- Keep exclusions minimal and test them against malicious as well as ordinary file modifications.
- Use current, non-deprecated binding algorithms and record their exact identifiers and parameters.
- Verify the completed signed asset independently before releasing it.
- Treat soft binding as an explicit product and privacy choice rather than a hidden default.
- Store the Manifest Store, soft-binding association, algorithm version, and repository receipt or ingestion evidence needed for later recovery.
- Preserve original assets and signed outputs so recovered candidates can be compared with authoritative records.
For validators, inspectors, and resolvers
- Report credential absence, hard-binding mismatch, exact hard-binding success, soft-binding recovery, and ambiguous recovery as different states.
- Never label a soft-binding match as though the current asset passed the original manifest's hard-binding validation.
- Verify the retrieved manifest's claim signature, assertions, certificate status, and trust independently of the soft match.
- Display the matching technology, the scope of the match, and algorithm-specific confidence or ambiguity when available.
- Use thumbnails, fingerprints, publication context, and human review where a recovered match could materially influence a decision.
- Protect URL-based or content-upload resolution against SSRF, oversized assets, decompression attacks, malicious media, and abusive query volume.
- Provide consent and client-side matching options where possible, and explain what data a repository query reveals.
- Retain the exact validation and resolver evidence used for a historical decision rather than recomputing it silently later.
Common misunderstandings
Misunderstanding | What is more accurate |
|---|---|
A hard binding survives resizing or transcoding. | A hard binding is intended for the protected representation. A transformation normally requires a new standard manifest. |
A soft binding proves that two files are identical. | A soft binding supports matching of related content and can be approximate or ambiguous. |
An invisible watermark is the Content Credential. | The watermark is a discovery signal. The structured, signed provenance remains in the C2PA Manifest Store. |
C2PA requires every asset to contain a watermark. | Soft bindings are optional. Standard manifests require a hard binding, not a watermark. |
A hard binding always covers every byte. | Format rules intentionally exclude the embedded manifest and may exclude other narrowly defined regions. |
A matching hash proves the content is true. | It proves integrity of covered content relative to the signed manifest, not factual truth. |
No repository match means the content is fake. | It means only that the chosen resolver found no match under the algorithms and repositories it queried. |
A watermark can be added after signing without consequence. | Watermark insertion changes the content. It should occur before the final hard binding or be followed by a new standard manifest. |
The simplest mental model
- A hard binding is the cryptographic seal on an exact protected representation.
- A soft binding is a durable search signal for finding related provenance after that representation changes or loses metadata.
- The claim signature protects both binding assertions through the signed claim.
- A manifest repository stores the provenance that a soft binding can help recover.
- A soft match is a candidate relationship, not a substitute for exact hard-binding validation.
- When a C2PA-aware system creates a new rendition, the strongest result is a new standard manifest with a new hard binding and preserved ingredient history.
Used together, hard and soft bindings give Content Credentials both precision and resilience. The hard binding provides a clear cryptographic answer about the asset being validated now. The soft binding provides a path back to provenance when real-world distribution has broken that exact relationship. A trustworthy implementation preserves the distinction at every stage - creation, recovery, validation, and presentation.
Sources and notes
[1] C2PA Technical Specification 2.4, "Binding to Content." This section defines the roles of hard and soft bindings and the rule that a manifest may contain no more than one hard-binding assertion and zero or more soft-binding assertions.
[2] C2PA Technical Specification 2.4, "Types of Manifests." This section specifies the exact hard-binding requirement for standard manifests and the absence of a new hard binding in update manifests.
[3] C2PA Technical Specification 2.4, "Hard Bindings" and the standard-assertion sections for data, BMFF, general-box, collection, and multi-asset hashing. These clauses define the available hard-binding structures and validation behavior.
[4] C2PA Technical Specification 2.4, "Soft Binding." This section defines the c2pa.soft-binding assertion, algorithm identifiers, scope, values, and the Soft Binding Algorithm List.
[5] C2PA Implementation Guidance 2.4, "Guidance on Hard Bindings" and "Guidance on use of Soft Bindings." These sections address exclusions, format-aware hashing, recovery, match verification, watermark actions, privacy, and repository tradeoffs.
[6] C2PA Soft Binding API 2.4, "Soft Binding Resolution API specification." This document defines interoperable query, fetch, store, and service operations for manifest discovery and repository use.