watermarking.media
Ownership

How to verify Content Credentials (and read the result)

By The watermarking.media team
5 min read
Contents

To verify Content Credentials you drag the file onto Content Credentials Verify, the free reader at verify.contentauthenticity.org, which reads the signed manifest and shows its assertions, its signing certificate, and its validation status, and a valid result proves the record is intact, not that the picture or the audio is true. Verifying is the easy part. Reading the result correctly is where most people go wrong, because the tool answers a narrow question, has this signed record been tampered with, that is routinely mistaken for a broad one, is this file real. This guide covers the single step to run the check and the context you need to read what comes back.

The one step: drag the file onto the reader

There is genuinely only one action. Open Content Credentials Verify at verify.contentauthenticity.org, then drag your file onto the page. The Content Authenticity Initiative describes what you get back as “a full breakdown of all assertions, the signing certificate, and validation status” (Content Credentials Verify). No account, no plug-in, and it reads an audio file the same way it reads an image. The same manifests can be read inside Adobe’s Content Authenticity Inspect tool, and developers can read them from the command line with the open-source c2patool (Content Authenticity Initiative), but for a one-off check the drag-and-drop reader is the shortest path.

What the reader actually shows

Three things come back, and they are not the same thing. Assertions are the individual claims recorded in the manifest: the digital source type (camera capture, AI-generated, or a composite) and the edit actions applied along the way (cropped, resized, colour-adjusted). The signing certificate identifies who signed the manifest and lets the tool check the signature. The validation status is the tool’s verdict on whether that signature still holds against the file in front of it.

Read them in that order. The digital source type is the assertion people care about most, because it is where a manifest declares a file as camera capture, AI-generated, or a mix. When it is present and the credential verifies, that is a real, signed statement about how the file was made. When it is absent, you have learned nothing, and that gap is the trap the rest of this guide is about.

Reading the result

Reader statusWhat it meansWhat it does not mean
TrustedSignature holds and the signer is on a recognised trust listThe content is true
ValidSignature is sound, but the signer is unverifiedThe signer is who they claim
InvalidCredentials could not be verified, e.g. the content changed after signingWho changed it, or why
No Content CredentialsNo manifest is present to readThe file is fake or suspect

Two of those rows look alike and mean opposite things. An Invalid result means a manifest is present but the content hash no longer matches the pixels or samples, which is positive evidence that the file changed after it was signed. A No Content Credentials result means there is no manifest at all, which is silent: it is indistinguishable from a file that never carried one. Presence is informative; absence is close to neutral. Treat the two as the same and you will read a routine re-encode as an attack, or miss that a signed file was quietly altered.

The ceiling: signals, not proof

Even a Trusted result has a hard limit, and it is the single most important thing to grasp before you lean on this tool. A Content Credential certifies that a record is intact, not that the record is honest. Point a C2PA-enabled camera at a screen showing a deepfake and it will sign a perfectly valid manifest for a fake image. The first independent security analysis of the standard put it plainly: “C2PA provides provenance signals, not proof of authenticity” (Golaszewski, Krawetz, Sherman, 2026). A valid credential tells you the chain of custody has not been broken. It does not adjudicate what the content shows.

Absence is weaker still, for a mechanical reason. The binding is a SHA-256 content hash wrapped in an x509-signed manifest inside the file, and the standard describes it as one “that ties the Manifest to the asset itself, ensuring that any changes to the asset will invalidate the Manifest” (Content Credentials Technical Whitepaper, 2025). A hash has no inverse, so the first changed byte invalidates it: 100 percent invalidation on any real edit (C2PA Specification v2.4). In practice the large majority of ordinary processing, a re-save, a resize, a format conversion, strips or breaks the credential incidentally. Most files were never credentialed, and many that were have lost the record in transit, so a blank result is the normal case, not a red flag.

A clean workflow

Run the reader, then hold to four rules. Read the assertions before the status, because “valid” is only meaningful once you know what was signed. Check the certificate and whether the signer is Trusted or merely Valid. Treat Invalid as evidence the file changed after signing, and No Content Credentials as non-evidence rather than a verdict. And remember a present, verifying credential is strong evidence that a signed history is intact, on an audio file as much as an image, while an absent one is the default state of almost everything online.

Once you can read a result, the natural next step is creating your own: attaching a credential in an editor, in Content Credentials in Photoshop and Lightroom, or signing a photo from scratch, in how to add Content Credentials to a photo.

Sources

#c2pa#content-credentials#provenance#verification#metadata