Skip to content

C2PA · 2026-08-17

What are C2PA Content Credentials?

The open standard behind every Content Credential Krusade attaches when you sign — portable, tamper-evident, and inspectable without trusting us.

A Content Credential is a cryptographically signed record that travels with a photo, video, or audio file. It answers a practical question: who signed this asset, when, and what claims did they attach? C2PA (Coalition for Content Provenance and Authenticity) is the open standard that defines how that record is structured, bound to the file's bytes, and checked by anyone with a conformant verifier.

Krusade uses that standard as the base of every successful sign. We do not invent a private badge. When you sign a file, Krusade builds a C2PA manifest, signs the claim, and embeds (or sidecars) the credential with your asset. Adobe Content Credentials, c2patool, and other independent tools speak the same format. That interop is the point: proof should survive upload, resize, and redistribution, and it should not depend on Krusade remaining online.

The credential is an envelope

Think of the Content Credential as an envelope. The envelope itself is C2PA: a signature, a hash binding to the asset bytes, and core provenance actions. Optional fields on the sign page—IPTC, EXIF, XMP, AI training preferences, licensing, Web3 references, signer identity—are assertions packed into that envelope. They appear only when you enable them, or when author and organization data applies.

If a product UI lists IPTC and EXIF but not a “C2PA” toggle, that is intentional. C2PA is not an optional extra. It is the container every successful Krusade sign produces. The toggles choose which extra claims ride along. That model is documented in What is C2PA? in the developer docs.

Why an open standard

An open, inspectable specification means you are not locked to one vendor's verifier. Tamper-evidence comes from the binding: edit the file after signing and verification fails or reports a break in the chain. Publishers, platforms, and creative tools are standardizing on Content Credentials so provenance can survive the path from capture to publish. Existing metadata standards can live as assertions inside one signed manifest instead of competing silos.

Krusade's role is the independent trust layer around that standard: organization identity, a signing API, and an audit trail. It is not a digital asset manager, not a blockchain, and not a private receipt-chain ledger. Files stay in your CMS, DAM, or CDN. Krusade stamps them at the publish handoff.

What happens when you sign

You choose a file and any optional standards claims. Krusade builds the C2PA manifest plus selected assertions and signs the claim. You download a signed file, or a sidecar ZIP if you asked for a detached manifest. Anyone can then check the result on Krusade's public verify page, via the public verify API, Adobe Content Credentials, or c2patool—no Krusade account required.

Unsigned files are not a failure in the verify API; they return a no_credentials status. Invalid means the cryptographic checks did not succeed. Valid means the credential checks out against the bytes. Trusted is a separate question about the certificate chain, covered in the FAQ and on the trust page.

Binding to bytes is the property people mean by tamper-evident. If someone opens a signed JPEG in an editor and hits save, the pixels or container usually change even when the picture looks the same. Verification then fails or reports a break, instead of quietly presenting the old credential as if it still matched. That is useful for brand impersonation and for “was this the file we actually published?” It is not DRM: it does not stop copying, and it does not prove that every downstream crop or social re-encode is authentic.

Platforms can still strip the manifest on upload. When that happens, a public verify of the downloaded file reports no_credentials. An invisible watermark can be detected and reported today; hosted recovery of the original credential after a strip is not shipping yet. Treat C2PA as the primary cryptographic record, and keep a signed original in your own CMS or DAM.

If you are new to the format, start with the C2PA docs, try signing a file, then verify it. The Docs describe the same flow for pipelines.