What is C2PA?

Every day, billions of images circulate online with no verifiable origin. A photograph might come from a Reuters photographer in Kyiv, or it might be a diffusion model hallucination generated in thirty seconds. The file itself offers no reliable way to distinguish between the two.

C2PA — the Coalition for Content Provenance and Authenticity — is an open technical standard that embeds cryptographically signed provenance data directly into media files. Rather than guessing whether content is authentic, you can verify it. The signature either checks out or it doesn't.

C2PA (Coalition for Content Provenance and Authenticity) is an open technical standard that uses cryptographic signing to embed verifiable provenance data directly into media files. It answers the question "who created this content, and with what tools?" with deterministic proof rather than probabilistic guessing.

This guide covers the specification in detail: its architecture, cryptographic underpinnings, trust model, current adoption, and honest limitations. If you are specifically looking for a C2PA architecture diagram and validation flow, the technical deep dive covers that separately.

C2PA verification in one minute

C2PA verification answers a simple question: does this image carry signed provenance metadata that still matches the file in front of you?

A verifier checks three things:

1. •Signature validity — was the manifest signed correctly, and does the certificate chain validate?
2. •Hash binding — does the content hash still match the current asset?
3. •Signer trust — is the signer one you actually trust for this use case?

If all three pass, you have verifiable provenance rather than a probabilistic guess. If you want the practical explainer first, read C2PA Verification. If you want the step-by-step technical flow, jump to How C2PA Content Credentials Work. If you want to test a real image, use the C2PA Viewer.

Latest C2PA specification version

The latest published C2PA specification is version 2.3. The specification is maintained in the open at c2pa.org. If you are comparing older explainers or implementation notes, check the version before relying on them — many articles still reference 2.1-era wording.

Origins and governance

C2PA was formally established in February 2021 by Adobe, Microsoft, Intel, Arm, and the BBC. It did not emerge from nowhere. Two prior initiatives converged:

• •Project Origin, a Microsoft and BBC collaboration focused on tackling disinformation in news media by attaching provenance to published content.
• •The Content Authenticity Initiative (CAI), founded by Adobe, The New York Times, and Twitter in 2019, which focused on building an open ecosystem for content attribution.

The organizations behind these efforts recognized they were solving the same problem from different angles. C2PA merged both lines of work under a single technical specification.

Governance sits under the Joint Development Foundation, a project of the Linux Foundation. The specification is developed in the open, and the latest published version is 2.3. Membership has grown to include Google, Nikon, Canon, Sony, Qualcomm, Truepic, and dozens of others. The specification is royalty-free.

The problem: metadata is not provenance

Digital images have carried metadata for decades. EXIF headers store camera model, GPS coordinates, exposure settings, timestamps. IPTC and XMP fields store photographer names and copyright notices. But none of this is trustworthy:

• •Metadata is trivially stripped. Upload a JPEG to most social media platforms and the EXIF data vanishes. Save a copy in many image editors and the fields are gone.
• •Metadata is trivially forged. EXIF editors are freely available. You can stamp any camera model, any GPS coordinate, any date onto any file.
• •There is no binding between the metadata and the pixels. Change the image, and the original metadata stays attached. The header says "Nikon Z9" but the pixels could be anything.

AI detection tools attempt to solve this from the opposite direction — analyzing pixels to guess whether content is synthetic. But statistical classifiers produce false positives and false negatives. They degrade as generative models improve. They cannot tell you who made something or what tools were used. They offer probability estimates, not proof.

C2PA takes a fundamentally different approach: cryptographic proof of origin, bound to the asset at creation time.

How C2PA works

The core mechanism is straightforward. A manifest is embedded in the media file. The manifest contains structured assertions about the content — how it was created, what tools were used, whether it was edited, and what the ingredients were. The manifest is signed with an X.509 certificate. The hash of the asset is included in the signed data, binding the pixels to the provenance record.

When you verify a C2PA asset, you are checking three things:

1. •Signature validity. Was the manifest signed by a certificate that chains to a known root? Has the signature been tampered with?
2. •Hash match. Does the hash in the manifest match the current state of the asset? If someone altered the pixels after signing, the hash breaks.
3. •Trust. Do you trust the signer? A valid signature from an unknown or self-signed certificate is cryptographically correct but operationally meaningless.

This is the same model that secures HTTPS, code signing, and email encryption — public key infrastructure applied to media files.

Manifest structure

A C2PA manifest is a CBOR-encoded data structure embedded in the file using JUMBF (JPEG Universal Metadata Box Format, ISO 19566-5). For JPEG and PNG files, this means a binary box inserted into the file structure. For video formats like MP4, C2PA uses the existing ISO BMFF box architecture.

A manifest contains:

Claim. The top-level structure that binds everything together. It references the assertions, identifies the claim generator (the software that created the manifest), and includes the asset hash.

Assertions. Typed data structures that describe the content. The specification defines several standard assertion types:

• •c2pa.actions — A list of actions performed on the asset. Each action has a type (like c2pa.created, c2pa.edited, c2pa.published, or c2pa.drawing) and optional parameters. This is the edit history.
• •c2pa.ingredients — References to source assets. If a Photoshop composite includes three stock photos, each appears as an ingredient with its own manifest reference. This creates a provenance chain.
• •c2pa.thumbnail — A thumbnail of the asset at signing time, so viewers can display what the content looked like when the signer attested to it.
• •c2pa.hash.data — The hard binding. A hash of the asset data that locks the pixels to the manifest.

Claim Signature. A COSE (CBOR Object Signing and Encryption) signature over the claim. This uses the signer's private key and includes the X.509 certificate chain.

A simplified view of the manifest structure:

{
  "claim_generator": "Adobe Photoshop 25.4",
  "assertions": [
    {
      "label": "c2pa.actions",
      "data": {
        "actions": [
          { "action": "c2pa.edited", "softwareAgent": "Adobe Photoshop 25.4" },
          { "action": "c2pa.color_adjustments" }
        ]
      }
    },
    {
      "label": "c2pa.ingredients",
      "data": [
        {
          "title": "IMG_4022.jpg",
          "relationship": "parentOf",
          "manifest_id": "urn:uuid:a1b2c3d4-..."
        }
      ]
    },
    {
      "label": "c2pa.hash.data",
      "data": {
        "algorithm": "sha256",
        "hash": "a7f1c3..."
      }
    }
  ],
  "signature": "<COSE signature with X.509 cert chain>"
}

(This is a simplified JSON representation. The actual encoding is CBOR within JUMBF boxes.)

Hard bindings vs. soft bindings

A hard binding is a cryptographic hash of the asset data included in the signed claim. If a single pixel changes, the hash breaks and verification fails. This is the primary integrity mechanism.

A soft binding is a perceptual hash or fingerprint that can survive certain transformations — resizing, recompression, format conversion. Soft bindings allow you to recognize that a modified file descends from a signed original, even after the hard binding breaks. The C2PA specification supports soft bindings but leaves the specific algorithms to implementers.

This distinction matters because images on the web are routinely transcoded. A JPEG uploaded to a social platform may be re-encoded at a different quality level, which breaks the hard binding. Soft bindings offer a degraded but still useful signal: "this image is very likely derived from that signed original."

The trust model

Here is where many explanations of C2PA stop too early. A valid cryptographic signature is necessary but not sufficient. You need to decide whether you trust the signer.

C2PA uses X.509 certificates — the same PKI infrastructure behind TLS. A signer holds a private key and a certificate issued by a certificate authority. When you verify a manifest, you check that the certificate chains to a trusted root.

But which roots do you trust?

The C2PA Trust List is maintained by the Content Authenticity Initiative. It includes certificate roots for organizations that have been vetted — Adobe, Google, Microsoft, major camera manufacturers, news agencies. If a manifest is signed by a certificate chaining to one of these roots, a conforming verifier treats it as trusted.

However, a self-signed certificate also produces a mathematically valid signature. A bad actor could sign manipulated content with their own certificate, and the cryptographic verification would pass. The signature is valid; the signer is unknown.

This is why trust list curation matters. AttestTrail maintains its own curated trust list with reputation scoring for known signers. When you verify an image through our API, we check the signature, match the signer against the trust list, and return a clear determination: is this signer recognized, and what is their track record? You can try it yourself with any C2PA-signed image.

The trust model is ultimately federated. Different verifiers can maintain different trust lists. A news organization might trust Reuters and AP but not a random camera manufacturer. A social platform might trust all CAI members. The cryptography is universal; the trust decisions are contextual.

Who uses C2PA today

Adoption has reached a tipping point across three categories: AI platforms, camera hardware, and media organizations.

AI-generated content

The most immediate driver is AI content labeling:

• •Adobe Firefly signs every generated image with C2PA credentials. Edits made in Photoshop's generative fill features are recorded as actions in the manifest.
• •OpenAI attaches C2PA manifests to images generated by DALL-E 3 and outputs from ChatGPT's image capabilities.
• •Google DeepMind applies C2PA metadata to images generated by Imagen. Google has committed to C2PA signing across its generative AI products.
• •Microsoft signs AI-generated images from Bing Image Creator and Copilot with C2PA manifests.

Camera hardware

Several camera manufacturers now embed C2PA manifests at the point of capture, which is the strongest possible provenance signal — the credentials are created by the camera's secure hardware before the image ever leaves the device. For a complete survey of supported hardware, see Which Cameras and Phones Support C2PA.

• •Nikon shipped C2PA support in the Z9 and Z8, using a Secure Processing Unit to sign images at capture.
• •Canon announced C2PA firmware updates for professional bodies.
• •Leica partnered with the CAI for C2PA signing in the M11-P, marketed as the first camera with built-in content credentials.
• •Sony has implemented C2PA signing in professional cinema and mirrorless cameras.

Media and publishing

• •The BBC was a founding member of Project Origin and has been integrating C2PA into its publishing pipeline.
• •The New York Times, a CAI founding member, has been exploring C2PA for photojournalism verification.
• •AFP, Reuters, and other wire services are evaluating C2PA for authenticating news photography.

Regulatory momentum

The EU AI Act, which entered into force in 2024, requires that AI-generated content be labeled in a way that is machine-readable. C2PA is the frontrunner standard for compliance. Article 50 mandates that providers of AI systems generating synthetic content must mark outputs in a machine-detectable format. The specification's open, interoperable design makes it a natural fit. For a detailed breakdown of the compliance timeline and requirements, see EU AI Act Article 50 & C2PA Compliance Guide.

Limitations

C2PA is important infrastructure, but it is not a silver bullet. Honest assessment of its limitations:

It does not prevent deepfakes. C2PA labels origin; it does not block creation. An unsigned image is not necessarily fake, and a signed image is not necessarily trustworthy — it depends on who signed it and what their assertions claim. C2PA shifts the question from "is this real?" to "who made this, and do I trust them?"

Credentials can be stripped. Because C2PA data is embedded in the file, anyone can strip it by re-encoding the image without the JUMBF boxes. Re-uploading through platforms that strip metadata removes the provenance. Soft bindings and the CAI's Content Credentials Cloud (a centralized registry) mitigate this, but the problem is real. Absence of credentials is not proof of forgery.

Adoption is incomplete. Most images on the internet today have no C2PA data. Most social platforms do not yet preserve or display content credentials when users upload media. Until the ecosystem reaches critical mass, C2PA is a signal that exists on some content, not a universal standard.

Certificate revocation is immature. If a signer's private key is compromised, their certificate must be revoked. The C2PA specification supports OCSP and CRL checking, but the revocation infrastructure for media signing is less mature than what exists for TLS. Timely revocation is an operational challenge.

Performance overhead. Verifying a C2PA manifest requires parsing CBOR/JUMBF structures, validating X.509 certificate chains, checking hashes, and potentially following ingredient references. For a single image, this takes milliseconds. For bulk verification of thousands of images (content moderation pipelines, newsroom ingestion), the overhead is nontrivial and requires dedicated infrastructure — which is precisely what the AttestTrail API provides.

C2PA vs. alternatives

C2PA is not the only approach to content authenticity. Here is how it compares to the common alternatives.

vs. EXIF / XMP metadata

EXIF and XMP are descriptive metadata — they record information about a file but provide no cryptographic binding. There is no signature, no hash, no verification mechanism. Any field can be edited or removed with freely available tools. EXIF tells you what the file claims about itself. C2PA proves what a verified signer attests.

vs. SynthID (Google)

SynthID is a Google DeepMind technology that embeds imperceptible watermarks into AI-generated images (and text and audio). It is designed to survive screenshots, cropping, and recompression. Key differences:

• •SynthID is proprietary and only available through Google's products. C2PA is an open specification anyone can implement.
• •SynthID is detection-oriented: it answers "was this made by a Google AI model?" C2PA is attribution-oriented: it answers "who made this, with what tools, from what sources?"
• •SynthID watermarks are invisible and survive transformations. C2PA metadata is explicit but can be stripped.
• •The two are complementary, not competing. Google applies both C2PA metadata and SynthID watermarks to its AI-generated images.

vs. blockchain provenance

Several projects (Numbers Protocol, Starling Lab, others) have explored recording content provenance on blockchains. The appeal is immutability and decentralization. The drawbacks are significant:

• •Cost and latency. Recording every image's provenance on-chain is expensive and slow compared to embedding a signed manifest in the file.
• •Privacy. On-chain records are public by default, which creates problems for sources who need to share content confidentially.
• •Scalability. Billions of images are created daily. No public blockchain handles this volume at reasonable cost.
• •Complexity. End users and developers need to interact with wallets, gas fees, and chain-specific tooling.

C2PA achieves cryptographic integrity without a blockchain. The signed manifest travels with the file. Verification requires only the file and a trust list — no chain queries.

vs. AI detection classifiers

AI detection tools (Hive, Illuminarty, various academic models) analyze pixel-level statistics to classify content as real or synthetic. They are useful as probabilistic signals but have fundamental limitations:

• •False positives. Legitimate photographs are regularly flagged as AI-generated, particularly after heavy editing or compression.
• •Adversarial fragility. As generative models improve, the statistical artifacts that detectors rely on become harder to find.
• •No attribution. A classifier might estimate "85% likely AI-generated" but cannot tell you which model, which prompt, or which user created the image.
• •No chain of custody. Detectors analyze the final output. C2PA records the entire provenance chain — creation, edits, ingredients, and export.

AI detection and C2PA serve different purposes. Detection is a forensic heuristic. C2PA is a provenance record. Robust content verification uses both. For a detailed comparison, see C2PA vs AI Detection: Why Cryptographic Proof Beats Probability.

Verification in practice

Reading the specification is one thing. Verifying real-world images is another.

The open-source c2patool CLI from the CAI lets you inspect manifests locally. Adobe's Content Credentials website offers a web-based viewer. But for integration into applications, moderation pipelines, and automated workflows, you need an API.

AttestTrail's verification API extracts and validates C2PA manifests, checks signer certificates against a curated trust list, and returns structured results — signer identity, trust status, assertion details, and a deterministic moderation decision. No probabilistic guessing. The signature is valid and the signer is trusted, or it is not. If you want the shorter walkthrough of what a verifier actually checks, see C2PA Verification.

You can try it now: upload any image to the C2PA Viewer to see its content credentials parsed and verified in real time.

C2PA is not a hypothetical standard waiting for adoption. It is shipping in cameras, AI platforms, and publishing tools today. The specification is mature, the governance is credible, and regulatory tailwinds are accelerating deployment. The remaining challenge is ecosystem completeness — getting every platform, every tool, and every workflow to preserve and surface provenance data.

The images are already being signed. The question is whether your systems can verify them. For a practical guide to integrating C2PA verification into your platform, see Building a Content Moderation Pipeline with C2PA.