Why C2PA doesn't solve screenshots

What C2PA does well

At its core, C2PA defines a manifest: a JSON-based block of provenance claims (capture device, edit history, generator info), cryptographically signed by the originating tool's key, embedded in the file. The manifest is structured so each edit step (Photoshop adjustment, AI tool output, color correction) can be appended as a signed claim — producing a chain of custody readable by any C2PA-aware viewer.

The strengths:

• Identity binding. The signing key belongs to a specific device or tool, often with a verifiable certificate chain back to a manufacturer or issuer. Readers know who signed what.
• Edit history. Each modification step is a signed claim. A downstream viewer sees the full chain; tampering breaks the signatures.
• Standards-grade. Maintained by a working group with broad industry membership; adopted by major news organizations (BBC, NYT) and generation tools (OpenAI, Adobe, Stability) as of 2026.
• Camera-side capture. Top-end cameras (Sony A1, Leica M11-P) sign at the moment of capture. The credential is part of the image file from the start.

Where C2PA structurally doesn't fit

C2PA depends on the capture device — or the generating tool — cooperating with the standard. The credential is created at the source. This is fine if you control the source. It breaks down for the most common kind of evidence on the internet today: screenshots of content on someone else's device or service.

Consider the chain for a typical “I screenshotted this tweet before it was deleted” case:

1. The original poster wrote the tweet on their phone or laptop, using a Twitter client that doesn't sign at composition time.
2. Twitter rendered the tweet to your screen via a web view or app.
3. Your OS's screenshot facility captured the rendered pixels — without C2PA awareness, because the OS isn't a C2PA-signing surface.
4. You saved the screenshot file with no credential.

There's no point in this chain where C2PA could have signed: the originator didn't (their client isn't C2PA), the platform didn't (Twitter doesn't serve C2PA-credentialed renders of tweet pages), and your OS's screenshot facility didn't (because screenshot facilities in iOS, Android, Windows, macOS, Linux are all unaware of C2PA in 2026). The credential simply isn't in the file you ended up with.

Can you “add C2PA” to a file later?

Technically yes — you can sign a derivative claim, asserting “I (this tool / this account) am attaching this signed claim to this file as of this timestamp.” This is cryptographically valid; it just doesn't mean what people often think it means.

A derivative-claim signature attests only to the signer's handling from the moment of signing forward. It does not attest to the file's provenance before the signer touched it. That's structurally identical to what a receipts.you seal does. The C2PA standard is most powerful when the chain starts at capture; weakening it to start at a seal step brings it to functional parity with simpler cryptographic-timestamp tools — at the cost of significantly more setup complexity.

What fills the gap

Seal-side provenance: cryptographic timestamping of an existing file, anchored externally so the timestamp is verifiable independent of the signer. Receipts.you does this for screenshots; the underlying primitives are SHA-256 + ECDSA + OpenTimestamps anchoring. The receipt page is a viewer that works in any browser — no special C2PA tooling required for the downstream reader.

The honest comparison:

• C2PA answers “who created or edited this file, and what's the edit history?” — when the source supports it.
• Receipts.you answers “when did this exact file exist?” — for any file, from any source, even if no upstream tooling was C2PA-aware.

They're complementary, not competing. A photojournalist on assignment in 2026 uses both: C2PA on the camera (signs every frame at capture); receipts.you on any social-media screenshots collected during the same investigation (because those screenshots can't be C2PA-signed at capture — the source isn't C2PA). One investigation, two tools, two different evidence shapes.

What about future C2PA adoption?

The optimistic future where C2PA is universal — every camera signs, every browser shows credentials, every OS-level screenshot tool signs — would close some of the gap. Screenshots of C2PA-rendered web content could carry forward a derived credential proving “this screenshot was taken from a page that was itself signed.” The credential would attest to the underlying rendered content, not just to the screenshot file.

Two reasons this future doesn't make seal-side provenance obsolete:

1. Coverage will never be complete. DMs, in-app content, paywalled material, legacy systems, and adversarial tools (anything specifically designed to avoid signing) will remain outside C2PA's coverage. Seal-side provenance works for files in any of these categories.
2. The screenshotter's own custody chain still matters. Even if C2PA covered the source content, the screenshotter's file still needs its own provenance if they want to prove “I had this specific copy at this specific timestamp.” That's a seal-side question, not a capture-side one.

The pragmatic recommendation

For 2026, the working pattern is:

• If you control the camera and it's C2PA-capable, sign at capture.
• For all the other cases — screenshots, files received from others, legacy material, anything not C2PA-aware at source — seal with receipts.you (or an equivalent seal-side tool).
• Treat the two as one chain. Mention both in your evidentiary methodology when the matter goes formal.

C2PA is good engineering. Receipts.you is good engineering. They cover different parts of the provenance landscape, and confusing them for each other does both standards a disservice.

For the full axis-by-axis comparison, see receipts.you vs. C2PA. For related notes on why EXIF metadata isn't a substitute for either, see EXIF metadata isn't proof.