How to verify content provenance and check Content Credentials

Verifying content provenance means checking a file for Content Credentials, the signed C2PA manifest that records who made the content, with what tools, and what was done to it. The fastest check is the official Verify tool at contentcredentials.org/verify: upload the file and read the result. For engineering workflows, the open-source c2patool does the same from the command line. The judgment part comes after the tooling: knowing what a green result actually proves, and what to conclude (very little) when no credentials are found.

This guide gives the verification steps in order, then the edge cases that trip people up: stripped metadata, re-encoded files, screenshots, and signers that are valid but unfamiliar. For background on what a manifest is and who backs the standard, see C2PA explained.

Step 1: Look for a provenance indicator where the content is displayed

Before downloading anything, check the surface you are looking at. Platforms and tools that support Content Credentials display an indicator, most commonly the “CR” Content Credentials pin, on media that carries them. LinkedIn shows credential information on images that have it, and TikTok labels AI-generated content that arrives carrying Content Credentials (adoption overview). Adobe applications offer built-in inspection of Content Credentials, and Digimarc ships a Chrome extension that checks images on any web page as you browse.

If an indicator is present, the platform has already validated the manifest for you; click through to read the details. If there is no indicator, do not conclude anything yet. Most surfaces on the web do not display credentials even when the underlying file has them, and many strip them entirely (Step 6).

Step 2: Run the file through the Verify tool

Get the file itself, ideally the original, not a screenshot or a re-save, and go to contentcredentials.org/verify. Upload the file or paste a direct URL. The tool locates the embedded C2PA manifest, validates the signature chain, re-hashes the content against the manifest’s hard binding, and renders the provenance in plain language.

Three outcomes are possible:

Step 3: Read the manifest details, not just the verdict

A valid result is the beginning of the assessment, not the end. Expand the details and read:

• The signer. Which organization’s certificate signed this? This is the single most load-bearing field: the credential is exactly as trustworthy as this entity. “Signed by OpenAI, marked as AI-generated” (OpenAI attaches C2PA metadata to its generated images) tells a very different story from “signed by an unknown self-signed certificate.”
• The actions. What does the manifest say happened: captured, created by an AI model, edited, composited? C2PA manifests record AI generation explicitly via the digital source type on the creation action.
• The ingredients. If the asset was edited, the manifest chains back to prior versions. Walk the chain: where did this start, and what changed at each step?
• The timestamps. When was it signed, and is the signature countersigned by a timestamp authority?

Step 4: Check whether the signer is on the C2PA trust list

Conforming validators distinguish between “cryptographically intact” and “signed by a recognized entity.” Under the C2PA Conformance Program, certificates used for signing should chain to an authority on the official C2PA trust list. The Verify tool surfaces this distinction for you: a manifest signed with a certificate outside the trust ecosystem will validate structurally but be flagged as not from a known source.

Anyone can generate a self-signed certificate and produce a technically well-formed manifest. The trust list is what separates “someone signed this” from “an accountable, identified organization signed this.” Treat unrecognized-signer results with the same skepticism as no credentials at all, unless you have an independent reason to trust the signer.

Step 5: Use c2patool for deep or batch inspection

For engineering and moderation workflows, the command-line c2patool (developed in the c2pa-rs repository) reads a file and emits a JSON report of every manifest it contains: assertions, ingredients, certificate details, and validation status. This is the right tool when you need to:

• verify assets in CI or an ingest pipeline rather than one at a time in a browser,
• inspect the raw assertion data behind the friendly UI summary,
• or archive validation reports as evidence alongside the assets themselves.

The same capability is available as libraries (Rust, Node, Python, browser JavaScript) if you are building verification into a product; see implementing Content Credentials.

Step 6: If no credentials are found, check for recoverable provenance

Absence of credentials is the default state of the internet, for two reasons: most content was never signed, and much of the content that was signed has had its metadata stripped in transit. Many platforms and CDNs re-encode uploads and discard embedded metadata wholesale, which removes the C2PA manifest along with everything else.

The ecosystem’s countermeasure is durable Content Credentials: pairing the embedded manifest with an invisible watermark and a content fingerprint, so that when the metadata is gone, the watermark or fingerprint can be used to look the manifest back up in a repository (the three pillars of provenance). C2PA calls this recovery mechanism soft binding, and Adobe operates a soft binding resolution API that resolves watermarked or fingerprinted assets back to their manifests. The Verify tool applies this where it can, which means a stripped file may still recover its provenance if the original was signed by a system that implemented durable credentials.

So when a file shows no credentials: try the Verify tool anyway (recovery may work), then try to trace the earliest obtainable copy of the file, closest to the source, and verify that instead.

Step 7: Corroborate outside the file

Provenance verification is one signal, not a verdict. Whatever the manifest says, corroborate against context: the account that posted it, the earliest appearance you can find, coverage by parties with independent knowledge, and, for high-stakes cases, forensic analysis. This matters in both directions. A file with no credentials is not fake, and a file with valid credentials is not true: C2PA proves who signed the content and that it has not changed since, never that the scene it depicts is honest. Our page on verifying media origin covers the broader corroboration workflow.

Edge cases that trip up verification

Stripped metadata. The dominant failure mode. Uploading through most social platforms, messengers, or image CDNs removes embedded manifests. A stripped file verifies as “no credentials found” even if the original was signed seconds earlier. Always ask: is this the original file, or a platform’s re-processed copy?

Re-encoding and edits outside the chain. Any byte-level change after signing (recompression, resizing, format conversion, an EXIF rewrite) breaks the hard binding even when it preserves the manifest, so Verify reports the content as changed since signing. That is the system working as designed: it cannot distinguish an innocent recompress from a malicious pixel edit, so it refuses to vouch for either.

Screenshots. A screenshot is a brand new image of your screen. It inherits nothing: no manifest, no watermark in most cases, no provenance. Screenshots are the simplest and most common way provenance dies.

Platform round-trips. Content downloaded from a platform and re-uploaded elsewhere may pick up the platform’s own processing and, in some cases, new labels. The manifest chain, if it survives at all, reflects that handling: read the ingredient chain rather than assuming the top-level signer is the creator.

Valid but misleading signers. A manifest signed by a real organization attests to that organization’s handling, and nothing more. A bad actor can sign misleading content with a perfectly good certificate; then the credential correctly tells you who to hold accountable. That accountability, not truth-detection, is the guarantee.

Legacy or malformed manifests. The specification has evolved (current line documented at spec.c2pa.org), and validators have grown stricter. Old assets signed under early versions may produce warnings in modern validators. For adversarial inputs, treat manifest fields as untrusted data; the CAI’s c2pa-attacks tool exists precisely because display code has to handle hostile manifests safely.

The bottom line

Verification is cheap, fast, and worth making a habit: check the display surface, run the file through Verify or c2patool, read the signer and the action chain, and weight the result by whether the signer is recognized. Interpret the outcome with discipline: valid credentials prove origin and integrity, warnings prove change, and absence proves only absence. For why watermarks are the fallback layer when metadata dies, read C2PA vs watermarking.

Webisoft builds provenance verification into products and content pipelines, from ingest-time validation to user-facing credential display.