What C2PA Content Credentials Look Like in Real Images

You've probably seen the small "CR" pin icon on AI images in the wild. That's C2PA Content Credentials — a cryptographic signature embedded directly inside the image file. When present, it's a statement from the producer about who made the file, with what tool, and what edits have been recorded since. Verifying that statement is a math problem, not a heuristic.

This post walks through what's actually inside a Content Credentials manifest, what it looks like across different signers, and what you can — and can't — conclude from a verified signature.

Where the signature lives

C2PA stores its manifest as a JUMBF box embedded in the image file. For JPEG, it goes into App11 segments; for PNG, into a custom chunk; for HEIC, into a metadata box. The bytes are tagged so that any C2PA-aware reader can find and validate them without disturbing the image data itself.

The signature covers a hash of the image bytes plus the manifest data. If you change a single pixel without re-signing, the hash mismatch invalidates the manifest. If you re-sign, the new signature appends to a chain — you can see who made every successive change.

What's inside a real manifest

When our detector reads a C2PA-signed image, you'll see fields like:

• Signer / claim generator — software or hardware that produced the file. Examples: Adobe Photoshop, OpenAI DALL-E 3, Sony Alpha 7R V, Leica M11-P.
• Validation status — valid, untrusted, or invalid. Valid means the signature checks out against a trusted root. Untrusted often means the signer's certificate isn't in the verifier's trust list (common during early rollout).
• Signed at — UTC timestamp from the signing operation.
• Generative declaration — boolean flag indicating whether the producer self-reports as AI-generative. Required for OpenAI, Adobe Firefly, Microsoft Designer, etc.
• Software agents — list of tools involved. A Photoshop edit of an originally Firefly-generated image will show both.
• Edit history (claim list) — chain of operations recorded between the original and now: cropped, color-corrected, generative-fill, etc.

Our image detector renders all of these in the C2PA panel when a manifest is present.

Walk-throughs across signers

OpenAI DALL-E 3 / GPT-Image-1

A fresh DALL-E 3 export carries:

• Claim generator: OpenAI / DALL-E 3
• Generative: true
• Software agent: c2pa-rs (the Rust signer Adobe and OpenAI both use)
• Edit history: created
• Signed at: time of generation
• Validation: typically valid (OpenAI's cert chains to a recognized root)

The manifest doesn't include the prompt — OpenAI explicitly chose to omit prompts for privacy. It does include enough to confidently call the file AI-generated, with provenance to OpenAI specifically.

Adobe Firefly / Photoshop generative-fill

Firefly exports look much like DALL-E 3, with Adobe Firefly as the signer. Photoshop edits — especially generative-fill — append an entry to the edit chain noting that a generative tool was applied to a region.

This is more nuanced than a simple "AI / not-AI" binary: a real photo with one generative-filled patch will be C2PA-signed as a real photo with a generative edit recorded. The signature tells you both: the original image was real, and an AI tool was used afterward.

Sony Alpha cameras (Alpha 7R V, Alpha 1, etc.)

Sony's authenticity-mode cameras sign at capture. The manifest includes:

• Claim generator: Sony Alpha 7R V (or specific model)
• Camera serial number (when configured)
• Capture timestamp
• Generative: false
• Edit history: captured

This is the strongest possible "this is a real photo" signal: a known camera, known operator, known time, validated cryptographically. News organizations are increasingly requiring this on submitted material.

Leica M11-P

The first consumer C2PA-signing camera carries a similar manifest to Sony's. Leica went a step further with optional public-key registration to make verification easier for end-readers.

Newsroom pipelines (BBC, AP, AFP, Reuters)

News organizations that adopt C2PA sign at multiple stages: capture, ingestion, edit, publish. Their manifests have long edit chains because every stage adds an entry. A photo that goes from a Sony camera through a BBC editorial desk through publication has a chain showing every hop.

When you see this chain in a C2PA panel, you're looking at the full provenance of a piece of news media — something that was previously impossible to verify externally.

What a "valid" signature actually proves

A valid C2PA signature, against a trusted root, proves three things:

1. The file's bytes have not been altered since signing
2. The signer was in possession of the private key associated with the certificate
3. The metadata claims (signer name, timestamp, generative flag, edit chain) are bound cryptographically to those bytes

It does NOT prove:

• That the signer is who you think they are (depends on certificate authority)
• That the metadata claims are true in any deeper sense (the signer could lie in their own manifest — they just can't lie and sign at the same time without exposing themselves)
• That AI was not involved earlier than the first signed entry (e.g., AI-generated content saved as PNG, then loaded into a Sony camera... no, this isn't possible, but you get the idea)

What a valid signature mostly does is: it makes lying expensive and traceable. A signer who lies is signing a publicly verifiable lie.

What an "untrusted" signature looks like

Sometimes our C2PA panel shows untrusted in the validation field. This usually means:

• The signer's certificate is valid but doesn't chain to a root in the trusted list
• The signer is using a self-signed certificate (common during testing)
• The certificate has expired since signing (rare)

Untrusted does NOT mean fake. It means "I can verify the manifest hasn't been altered, but I can't independently confirm who the signer claims to be." For most workflows, this is fine to surface alongside the manifest contents — the user can decide how much weight to give the signer's identity.

What no signature looks like

Most images on the internet today carry no C2PA at all. Our detector handles this gracefully — the C2PA panel shows "not present" and falls back to forensic signals (ELA, FFT, channel split, noise residual). Absence of a signature is not evidence of fakery; it's just absence of evidence either way.

The trajectory is clear though: C2PA adoption is accelerating across cameras, AI tools, editing software, and publishing platforms. Within a few years, most professionally-produced images will carry signatures. Detection will remain useful for the long tail of unsigned content.

How to read a manifest in our tool

Drop any image (signed or not) into the image detector. When a manifest is present, you'll see:

• C2PA badge at the top — verified, untrusted, or not present
• Signer pill — who signed it
• AI-generated badge — when the manifest declares generative content
• Full Content Credentials panel — signer, validation status, signed timestamp, generative flag, software agents, recorded edits

Try it on any DALL-E 3 image (right-click → "Show Content Credentials" in some viewers, or just upload to our tool). Try it on a recent BBC news image. The difference between "no manifest" and "signed by a major source" is the future of trust on the internet.

The bottom line

Content Credentials make image authenticity a math problem instead of a vibe problem. Forensic detection is still useful for unsigned content (most of the web, today), but it's the bridge to a world where you check signatures the way browsers check SSL.

We read C2PA before any heuristic runs. When a valid manifest is present, the verdict is clear and the case closes; the forensic signals become supplementary detail. When no manifest is present, we run the full forensic stack and surface every signal so you can audit the call yourself.

Run an image through our tool → — the C2PA panel appears whenever a manifest is found.