C2PA Viewer: Read and Verify Content Credentials

Drop a file in and see what its manifest actually claims: which tool made it, what actions are recorded, what the digital source type says, and whether the signature holds up. We show the raw fields and the validation result side by side, because a green check alone is not a conclusion.

Open a file

No manifest is a normal result, not an error. It means there is nothing to read.

What a C2PA manifest contains

C2PA is an open technical standard, published by the Coalition for Content Provenance and Authenticity, for attaching a signed record of how a file was created and edited. Adobe's Content Credentials is one implementation of it. Practically, the manifest is a small signed data structure embedded in the file itself, and it holds five things worth reading:

Claim generator — the software and version that produced the manifest.
Actions — the recorded history, such as created, edited, converted, or published, each with a timestamp.
Digital source type — the IPTC value describing origin, for example digital capture for a camera, or trained algorithmic media for a generative model.
Ingredients — hashes of the files that were combined into this one, which is how composites and face swaps become visible.
Signature and certificate — who signed it, and whether that signer chains to a trusted authority.

What this viewer shows

Field	What it means	Why it matters
Claim generator	The app and version that created the manifest.	Names the tool directly. A generative model's name here is the strongest single signal on the page.
Action history	Each recorded step, with timestamps in the order they were asserted.	Shows whether the file was only captured, or captured and then edited elsewhere.
Digital source type	The IPTC origin code, such as digital capture or trained algorithmic media.	Distinguishes a photo taken by a camera from one generated or heavily synthesized.
Ingredients	References to the source assets that were combined.	Composite and face-swap work leaves evidence here that pixel analysis often misses.
Signature and signer	Whether the cryptographic signature verifies, and who issued the certificate.	Determines whether this record is usable as evidence, or only as a hint.
Hard binding	The hash of the file content at signing time.	Recompute it and any later edit shows up as a mismatch. This is how tampering surfaces.

How to read the result

Four outcomes are possible, and they mean very different things. Most viewers collapse them into a single pass or fail, which is where misinterpretation starts.

Result	What it actually means	What to do
Signature verified, signer trusted	The content matches the signed hash, and the signer chains to an authority on a trust list.	Read the actions and source type. Trust the record, then judge the file on what it says.
Signature verified, signer unknown	The math checks out, but the certificate is self-signed or not on any trust list.	Treat the record as unverified provenance. Anyone can produce this.
Manifest present, validation failed	The file changed after signing, or the manifest does not match its container.	Strong signal that the file was altered after the record was made. Get the original.
No manifest	Nothing is embedded. Nothing more.	No conclusion. Most real files land here. Do not read it as either clean or fake.

Hard bindings, soft bindings, and why edits break them

A hard binding is a cryptographic hash of the file content, so any byte-level change after signing breaks it. That is why editing a file with a tool that is not C2PA-aware usually destroys the manifest: the editor rewrites the bytes and does not know to update the signature. A soft binding works differently — it is a watermark or a perceptual fingerprint that can survive some re-encoding. Soft bindings are easier to damage and easier to forge; they are a recovery aid, not proof. When you see a manifest attached to a file that has clearly been edited, check which binding is present before you draw conclusions.

When the file has no Content Credentials

This is the most common result and the most misread one. Absence of a manifest does not mean the file is fake or AI-generated. Reasons a real photo has no manifest include:

The camera or app that captured it does not attach credentials at all.
It passed through a messaging app, social platform, or screenshot, any of which strips the manifest.
It was edited by software that reset the file structure.
It was downloaded from an archive that removed embedded data.

Conversely, presence of a manifest does not mean the file is real. Read the source type and the action history. If you need to go further, run the same file through the deepfake detector for the statistical side.

What this viewer cannot tell you

It cannot prove a capture is truthful. A valid record says how the file was made, not whether the scene was real.
It says nothing before the first signature. Everything up to that moment is unrecorded.
It cannot recover a stripped manifest from a screenshot or a platform re-encode.
It does not judge whether a source type is honest. A signer can declare the wrong type; the signature only shows the declaration was not altered.

Full detail on thresholds and failure modes is in our methodology.

C2PA viewer, C2PA checker, metadata viewer — the difference

These get used interchangeably, and the difference matters when you need a defensible answer.

A C2PA viewer shows the whole manifest: history, ingredients, source type, signer.
A C2PA checker returns a verdict: present or absent, valid or not.
A metadata viewer reads EXIF and XMP, which is a different layer entirely and survives or disappears on its own schedule.

For a newsroom or a compliance file you want the first, plus the metadata, plus the validation result — which is what this page gives you. If you need it as a timestamped document, the forensic report option packages all three.

FAQ

What does a C2PA viewer show?

It reads the manifest embedded in a file and displays the claim generator, the recorded actions and edit history, the digital source type, the ingredients the file was built from, and the signature status. The signature status is the part most other viewers skip: a mathematically valid signature is not the same as a signer you should trust.

Does a missing Content Credential mean the image is AI-generated?

No. Most files in circulation have no manifest at all. Many cameras and editing tools still do not attach one, and most platforms strip metadata and embedded manifests on upload. A missing credential tells you nothing about how the file was made.

Can C2PA metadata be faked or stripped?

Both are possible. Stripping is easy: a screenshot, a screen recording, or a re-encode through most social platforms removes the manifest. Faking a valid signature requires a certificate that chains to a trusted authority, which is hard but not impossible for a signer that controls its own certificate. That is why the signer identity matters as much as the signature.

What is the difference between a C2PA viewer and a C2PA checker?

A viewer displays everything the manifest contains, including the full edit history and ingredients. A checker usually answers one question: does this file have valid credentials or not. We show the full manifest and the validation result separately, so you can see what passed and what did not.

Why does a file show a valid signature but still look suspicious?

An intact signature only proves the file has not changed since whoever signed it signed it. It says nothing about whether that signer was honest, or about what happened before the first signature. Always read the claim generator and the recorded actions, not just the green check.

Does C2PA work on video, screenshots, and social media uploads?

It works on video and PDF when the manifest is intact. It does not survive a screenshot, and it rarely survives a re-upload to a major platform. If a clip was re-encoded, expect no manifest, and treat the absence as no information rather than as a red flag.