Content Credentials are the consumer-facing name for a C2PA manifest: a signed record, usually embedded in the file, stating what produced an image and what was done to it afterward. The record is invisible in an ordinary image viewer. To see it you need software that parses the manifest, checks its signature, and decides whether the signer is one it recognizes. This page covers the tools that do that in 2026, from a drag-and-drop website to a command-line utility, and explains how to read what they report.
The short version: for a single image, upload it to the Content Credentials Verify site or to Adobe's Inspect tool. For images on web pages, use a browser extension. For a batch, a script, or a disputed result, use c2patool. Whatever the tool, a report of "no Content Credentials" tells you only that none were found in that copy of the file.
Content Credentials Verify
The Content Authenticity Initiative runs a free inspection site at contentcredentials.org/verify, which currently redirects to verify.contentauthenticity.org. You drop a file onto the page, or choose one with the file picker, and the site parses any manifest it finds and displays a summary: the issuer of the credential, the date it was signed, the app or device that produced it, recorded actions, and any ingredients (earlier assets the image was built from), with thumbnails where the manifest carries them.
Verify is built on the CAI's open-source SDK, the same code that powers c2patool. Its main limitation is the trust configuration. According to the CAI's own c2patool documentation, Verify currently evaluates signers against the legacy interim trust list, which is frozen and no longer accepts new certificates, rather than the official C2PA trust list used by products in the C2PA conformance program. A credential signed under a newer certificate can therefore be labelled as coming from an unknown source on Verify while another tool reports it as trusted. The trust list page covers why two lists exist.
Adobe Content Authenticity: Inspect and the Chrome extension
Adobe operates a second inspection tool, Inspect, as part of its Adobe Content Authenticity web app (the short address inspect.cr redirects to it). It accepts a dragged file or a screenshot and shows the same kinds of fields as Verify. It differs in two ways that matter for verification:
- Trust list. The CAI documentation states that Inspect uses the official C2PA trust list. For content signed by conformance-program products, Inspect is the more current reference.
- Recovery. When a file carries no manifest, Inspect can look for possible matches: credentials stored in Adobe's cloud that are linked to the image by an invisible watermark or a visual fingerprint. This is the durable Content Credentials mechanism in practice. A match is a lead, not proof: it says a credential exists for an image that looks like this one, and you still have to judge whether the two are the same picture.
Adobe also publishes the Adobe Content Authenticity extension for Chrome. Once installed, it scans the images on each page you visit, shows a count of detected credentials on its toolbar icon, and lists them; an Inspect button hands any one of them to the full Inspect view. The extension is useful on news sites and portfolios that serve original files. It will find nothing on most social platforms, because they strip or re-encode uploads (see platform policies). Digimarc has published a separate C2PA browser extension that performs a similar role.
Inside Adobe apps
Photoshop's Content Credentials panel (Window > Content Credentials) is primarily a producer-side feature: it records edits and lets you attach a credential at export, and it can preview the credential that will be written. It is not designed as a general inspector for files you received from someone else. For those, Adobe directs users to Inspect.
Platforms that show the CR label
A few consumer surfaces display provenance to people who never go looking for it:
| Surface | What you see | Notes |
|---|---|---|
| A small "CR" icon on images and video that arrive with Content Credentials; clicking it opens a summary | Summary shows the tool used, the issuer, the date, and whether AI generated or edited the content | |
| Google Search | "About this image" shows whether an image was created or edited with AI tools when C2PA metadata is present | Announced by Google in September 2024 |
| Google Photos | Capture and edit information drawn from Content Credentials | Launched with the Pixel 10 in 2025, rolling out more widely afterward |
These surfaces show a curated summary, not the whole manifest, and they do not explain their trust decisions in detail. They are good at telling an ordinary reader that a credential exists. When a result matters, download the original file where you can and inspect it with Verify, Inspect, or c2patool. See adoption status for which devices and generators produce credentials in the first place.
c2patool for full detail
The web tools summarize. c2patool, the CAI's open-source command-line tool, prints the manifest store as JSON, including every assertion, every ingredient, and the machine-readable validation results. Pointing it at a file is enough:
c2patool photo.jpg # manifest store as JSON
c2patool photo.jpg --info # size, manifest count, validation result
c2patool photo.jpg --tree # tree of manifests and ingredientsBy default c2patool checks structure and cryptography; whether a signer counts as trusted depends on which trust lists you configure. Installation, trust configuration, and signing are covered in the c2patool guide.
What each result means
Tools phrase their verdicts differently, but they map onto the validation states defined in the C2PA specification and exposed by the CAI SDK: a manifest is either invalid, valid (well formed and cryptographically intact), or trusted (valid, and signed by a certificate that chains to an entry on the configured trust list). Add the case where nothing is found, and there are four outcomes.
| Result | What it means | What it does not mean |
|---|---|---|
| Valid, trusted signer | The manifest is intact, the file matches the hash recorded when it was signed, and the signing certificate chains to the tool's trust list | That the scene is what the caption says, or that the signer's assertions are true |
| Valid, unknown or untrusted signer | The cryptography checks out, but the certificate is not on the trust list the tool uses. In SDK output this is the status code signingCredential.untrusted | Forgery. Self-signed test certificates, new certificates missing from an older list, and independent signers all land here |
| Invalid | Something does not verify: the file bytes no longer match the recorded hash (for example assertion.dataHash.mismatch), the signature fails, or the structure is broken | Necessarily malice. A tool that edits a file without updating its manifest produces this result routinely |
| No credentials found | No manifest was found in this copy of the file, and no recovery lookup matched | That the image is fake, AI-generated, or unsourced |
Reading an "unknown source" result
The unknown-signer case needs the most care, because it looks like a warning and is often benign. The CAI's own sample images, signed with a development certificate, produce it; so does any content signed before its issuer was added to the list your tool uses. Look at the certificate issuer the tool displays. If it names an organization you can check independently, the credential still carries information. If it names nothing meaningful, treat the manifest as an unverified claim by an unknown party: the file has not changed since that party signed it, and that is all.
Reading an "invalid" result
An invalid credential tells you the file was altered after signing by something that did not re-sign it. That includes deliberate tampering, but it also includes harmless re-saves by software unaware of C2PA. Look at which check failed. A hash mismatch on otherwise sensible assertions often means a re-export; a signature failure on the claim itself is more serious. Either way the manifest can no longer vouch for the pixels you are looking at, though its assertions may still be useful context about the original.
The reverse inference is also wrong. Anyone can sign a manifest, including over a fabricated image; a credential proves who signed and that the file has not changed since, not that the content is true. The limits of provenance page develops this point.
A practical sequence
- Get the most original copy you can: the file from the photographer or publisher, not a platform re-upload or a screenshot.
- Check it in both Verify and Inspect. If they disagree on trust, the difference is almost always the trust list, not the file.
- If no manifest is found, let Inspect search for possible matches, and treat any match as a lead to confirm.
- For anything you will publish or rely on, run c2patool and keep its JSON output with your notes.
- Whatever the result, continue with the rest of the verification workflow: reverse image search, metadata, and source contact. Provenance is one input, not a verdict.