You sign an image with Content Credentials, upload it, and on the other side the credential is gone. This is the single most common disappointment teams hit when they first adopt C2PA: embedded provenance gets stripped in transit, and the stripped file gives no hint a credential ever existed. Here is why it happens, what the standard does about it, and a delivery pattern that keeps the canonical signed record available through channels you control, even when a file loses its embedded metadata.
The problem: credentials vanish in transit
Standard C2PA stores its manifest inside the file, in a JUMBF data block. That works beautifully until the file passes through something that does not understand or preserve it. Most consumer platforms — messaging apps, social networks, image CDNs — re-encode uploads to normalize and compress them. Re-encoding rewrites the file and routinely discards the JUMBF block along with the rest of the metadata. The recipient sees a clean-looking image with no signal that it was ever signed.
Why re-encoding wins
This is not a bug so much as a mismatch of assumptions. Embedded metadata assumes the bytes arrive intact; distribution pipelines assume they are free to rewrite the bytes. When those assumptions collide, the metadata loses. And because a missing credential is indistinguishable from content that was never signed, stripping silently erases the very thing you added the credential to prove.
The standard’s answer: soft bindings
C2PA anticipated this and defines soft bindings: invisible watermarks or content fingerprints that let a verifier re-discover a manifest even after the embedded copy is gone. The watermark rides in the pixels themselves and can survive some re-encoding; a fingerprint lets a service match the content back to a stored manifest. Soft bindings genuinely help — but they are recovery by probability, not guarantee. They add a watermarking dependency, can be weakened by heavy edits or cropping, and require infrastructure to resolve the recovered identifier back to a manifest.
A different angle: decouple the record from the file
There is a complementary approach that sidesteps the failure mode at its root: stop relying on the credential surviving inside the file at all. If the signed provenance record is stored as its own object and delivered alongside the content, re-encoding the media cannot strip what was never embedded in the media. The file can be compressed, resized, or rewritten; the authoritative record lives next to it as data.
This is most natural when provenance is created at the publishing layer rather than at capture. The producing system already holds the canonical content and the signing key, so it can emit a signed record and serve it as a first-class API response. Verification then resolves the signer through a public key directory — not through the asset’s self-claimed metadata, which you should never trust anyway.
Provenance as data, delivered by API
Concretely, this looks like a content endpoint that returns the published content envelope plus its latest signed provenance record together — for example, GET /api/content/:slug returning both as JSON. A browser, a syndication partner, or a procurement reviewer fetches the pair, verifies the signature against the public key directory, and walks away with cryptographic confidence — without trusting the CMS vendor and without depending on whether a JUMBF block survived the journey.
This is the architecture behind a headless CMS with a built-in provenance layer. It does not compete with C2PA — Hessian also produces a C2PA manifest definition that embeds the signed Hessian record as a custom assertion, so it can feed the broader C2PA ecosystem. It just refuses to bet authenticity on the most fragile link in the chain.
One honest caveat: API delivery is durable within a relationship you control, where the consumer fetches the record by the content’s identifier. Once a file is copied, cropped, or re-encoded out into channels you do not control, nothing automatically binds that loose file back to your record — that is exactly the gap C2PA soft bindings (watermarks and fingerprints) exist to close. The two approaches are complementary, not rivals.
Which approach, when
- You control delivery (your site, app, or API). Deliver the signed record as data and verify against a key directory. Stripping is a non-issue.
- Content leaves into channels you do not control. Keep the durable record at the source, export a C2PA manifest for interoperability, and add soft bindings if you need best-effort recovery from raw files in the wild.
The takeaway
Embedded credentials are valuable but fragile. The durable move is to treat the signed record as the source of truth, deliver it as data through channels you control, and verify it independently — then add a C2PA manifest and soft bindings when content leaves for the open web. Start with content provenance basics, or see how Hessian delivers a canonical, independently verifiable record on the product overview.