A photo arrives in a group chat and someone asks whether it is real. The instinct is to ask a detector whether the picture is AI. Detectors guess, and for text at least, the published false-positive rates make that guess a poor foundation for a decision (what the commercial detectors publish about their own accuracy).
There is a second question, and it has a much cleaner answer. Not “does this look machine-made” but “does this file carry a signed record of its own history”. That record is the Content Credential, the manifest format specified by the Coalition for Content Provenance and Authenticity (C2PA). It is written into the asset or shipped alongside it, it is signed by a party whose certificate you can look up, and you can check it yourself. The specification is also unusually blunt about what a credential does not settle.
TL;DR
- A Content Credential is a signed manifest, not a label. The specification defines a claim as “A digitally signed and tamper-evident data structure that references a set of assertions, concerning an asset, and the information necessary to represent the content binding” (C2PA).
- The signature is bound to the pixels. A hard binding lets a validator confirm that the manifest belongs to this asset and that the asset has not been modified since (C2PA).
- Three ways to check. Google Search’s “About this image” panel, the Info panel in Google Photos, or the
c2patoolcommand line tool, which reports whether the manifest validated (Google, Google Photos, c2patool). - A credential proves provenance, not truth. The specification says it “DO NOT provide value judgements about whether a given set of provenance data is ‘good’ or ‘bad’” (C2PA).
- No credential is not a verdict. The harms assessment states that “The fact that any digital asset does not have Content Credentials does not mean that its contents are not to be trusted” (C2PA).
- Plain metadata is not a credential. Google warns that “credit and digital source type metadata can be modified with image generation and editing tools, so it may not be accurate” (Google).
- The signer is the trust, not the pixels. A claim generator must be on the C2PA trust list to sign trusted claims, and claim generators can only be non-human hardware or software actors (C2PA).
- Credentials can leak. A manifest may carry sensitive information, and redacted information can still turn up if a soft binding lookup is enabled (C2PA).
What a Content Credential actually contains
The plain-language version, from the Content Credentials glossary, is that a credential is “a digital record for a piece of content that can show where it came from and what’s happened to it along the way”, and it may include “when and where it was created, any edits or changes made (and with what tools), and whether AI was involved” (Content Credentials).
Underneath that sit four pieces of vocabulary, and the specification is precise about each one.
An assertion is “a statement either made (or “created”) by the signer or simply gathered at claim generation-time, concerning the asset”. Assertions are the actual claims: this was captured by a camera, this was edited by this tool, this was generated by a model. A claim is the signed container: “A digitally signed and tamper-evident data structure that references a set of assertions, concerning an asset, and the information necessary to represent the content binding.” A manifest bundles one claim, its assertions and its signature. The active manifest is the one a validator should read: “The last manifest in the list of C2PA Manifests inside of a C2PA Manifest Store which is the one with the set of content bindings that are able to be validated” (C2PA).
The binding is the part that makes this different from a sticker. A hard binding “enables the validator to ensure that (a) this manifest belongs with this asset and (b) that the asset has not been modified, by determining values that can match only this asset and no other, not even other assets derived from it or renditions produced from it”. The simplest form is a cryptographic hash “over some or all of the bytes of an asset”, so a re-encoded or retouched copy fails to match its manifest, and the specification says a validator must then “reject the manifest with a failure code of assertion.dataHash.mismatch” (C2PA).
One more rule matters when you are reading a tool’s output: if no manifest store can be found, “the asset shall be treated as if no manifests were located” (C2PA). A validator that reports nothing found is telling you the file has no credentials, not that the file is clean.
Three ways to check a file
In Google Search. Search for the image, open the image viewer, choose About, then “Learn more about an image”. Google’s help page describes a “How the image was made or edited” section that can tell you “whether an image was captured with a camera or generated with AI”, plus an “Info from” section that tells you who confirmed that these details are accurate. Two caveats travel with it: the feature “is currently only available in some regions”, and the metadata behind it can be edited by the very tools it describes (Google). In a September 2024 post, Laurie Richardson, Vice President, Trust & Safety at Google, wrote that Google was bringing Content Credentials to Search, where “If an image contains C2PA metadata, people will be able to use our “About this image” feature to see if it was created or edited with AI tools”, and that it would “validate content against the forthcoming C2PA Trust list, which allows platforms to confirm the content’s origin” (Google).
In Google Photos. On your computer, go to photos.google.com, select the photo you want to check, then select Info. Google documents that Photos surfaces information based on the International Press Telecommunications Council metadata standards: “IPTC includes copyright information, the creator’s name, captions or image descriptions. Sometimes AI edits are included, but can be edited or removed.” The same page notes that “You may also find digital watermarks like SynthID embedded into images edited with generative AI which will surface on tools like Google Search or Lens.” Google is equally clear about the weakness: “Note that IPTC metadata can be modified”, and “The AI info section is removed for photos that haven’t been edited with AI or that don’t follow IPTC standards” (Google Photos).
On the command line. This route gives you the whole manifest rather than a summary. c2patool is the open-source tool from the Content Authenticity project’s contentauth repositories: “a command line tool for working with C2PA manifests and media assets (audio, image or video files)” (C2PA Tool). Install it with brew install c2patool on macOS, or grab a prebuilt binary from the releases page (C2PA Tool). Then:
c2patool photo.jpg --infoThe usage documentation says the information report “Displays the size of the manifest store and number of manifests. It will report if the manifest validated or show any errors encountered in validation” (c2patool usage). Run the tool with just a filename and it writes the full manifest JSON to standard output. Other flags earn their keep: -d for the detailed low-level report, --certs to extract the PEM certificate chain behind the signature, --tree for a diagram of the manifest store, and -s to write the manifest to a .c2pa sidecar instead of embedding it (c2patool usage). The project keeps example files in a sample directory that you get by cloning the repository, so c2patool sample/C.jpg shows what a populated manifest looks like without hunting for one (C2PA Tool).
What a credential does not prove
This is where the standard is most useful, because it is specific rather than reassuring.
The specification draws the line directly: “C2PA specifications DO NOT provide value judgements about whether a given set of provenance data is ‘good’ or ‘bad,’ merely whether the assertions included within can be validated as associated with the underlying asset, correctly formed, and free from tampering.” The harms assessment puts it the same way: “The C2PA specifications do not provide value judgments about the truth or falsehood of digital assets” (C2PA, C2PA harms assessment). A valid credential means the chain of custody is intact. It does not mean the content is accurate: a photograph of a staged or misleading scene can still carry a perfectly valid credential.
The reverse error is just as common. Absence of a credential means the file has none, nothing more: “The fact that any digital asset does not have Content Credentials does not mean that its contents are not to be trusted” (C2PA harms assessment). The same assessment notes that creators may have legitimate reasons not to use C2PA-enabled tools, so a file with no manifest is an ordinary state of the world rather than a red flag. Treat a missing credential as missing information.
And a failing credential is not automatically an accusation. The harms assessment warns that “Invalid Content Credentials could mean that either the digital content or the manifest has been tampered with, though this may not always be the case” (C2PA harms assessment). Since the hard binding ties the signature to the asset’s bytes, a change made outside a tool that writes a new manifest breaks the match, so a failed match on a picture you know you edited that way is an expected result rather than a finding.
Keep three separate instruments apart. A credential is a signed manifest, cryptographically tied to the asset. A watermark such as SynthID is a mark “often invisible to the naked eye”, which is a different mechanism with different removal properties - a reverse-engineering write-up found Microsoft Paint embedding one in locally generated AI images (Content Credentials). A detector is a statistical guess with no claim on the file at all. Google Photos documents all three on one page: IPTC metadata with copyright and creator details, an AI edit notice, and the SynthID watermark, and it notes that the metadata can be edited or removed (Google Photos). Only the first of those three is tamper-evident.
Who is allowed to sign, and how to check
The trust model is about signers, not pixels. The specification defines the C2PA Trust List as “A C2PA-managed list of X.509 certificate trust anchors that issue certificates to hardware & software signers that use them to sign claims” (C2PA). The harms assessment notes that “As of version 2.0 of the specifications, implementers must be part of the C2PA trust list … to be able to sign trusted claims”, and that “Claim generators can only be non-human (hardware or software) actors”, so a trusted signature comes from listed hardware or software, not from a person acting alone (C2PA harms assessment).
That last point is the one people get wrong. A credential says a device or a piece of software made this assertion. It does not say a person made the image. The harms assessment states the consumer-side rule plainly: “If a content consumer trusts a particular signer, then they may be inclined to believe that the information in the Content Credentials is authentic”, and the whole trust model rests on that prior relationship (C2PA harms assessment).
The practical step is to look the signer up. The C2PA runs a conformance program that “provides assurance that products adhere to the Content Credentials specification, and fulfill a set of security requirements to ensure they are producing and validating C2PA data correctly”, and “Conforming products are placed on a publicly-accessible list” (C2PA). The same page links a Conformance Explorer for browsing the live conforming products list, the C2PA Trust List and the C2PA TSA Trust List.
The privacy cost
Credentials are metadata, and metadata leaks. The harms assessment lists privacy risks, and two of them apply to anyone publishing photos with a credential attached.
The first is disclosure: “C2PA claim generators may automatically add, or require to add, information to manifests that may be sensitive” (C2PA harms assessment). The second is harder to reason about, because it is about deleting: “Redacted (deleted) information from Content Credentials may still be accessible: If a soft binding lookup is enabled or required by manifest stores, then previous versions of a manifest with sensitive information may be located.” A credential that has been edited to hide a location, a device identifier or an author’s name may still be recoverable.
So before you publish an image with a credential on it, read the manifest first. The JSON that c2patool prints by default shows you what the assertions actually say, including anything you did not intend to publish (c2patool usage).
What this means
Provenance and truth are different properties, and only one of them is checkable from the file. The C2PA machinery gives you a signed, tamper-evident statement about how an asset came to be, plus a way to verify that statement has not been tampered with. It deliberately stops short of judging the result, and it says so in the same document that defines the format.
The practical consequence is a change in what you ask. Instead of asking whether an image “looks AI”, ask whether it carries a credential, whether that credential validates, and who signed it. That is a question with an answer, and the answer is in the file.
The limits are equally clear. A credential only exists where a tool chose to write one, so a missing one is a gap in the record rather than a finding. And where plain metadata is shown instead, treat it as a hint: Google says, in both the Search and the Photos help pages, that this metadata can be edited or removed (Google, Google Photos).
The bottom line
Check the credential before you judge the picture. The command is c2patool photo.jpg --info, and it tells you whether the manifest validated and what the failures were if it did not. The panel in Google Search and the Info panel in Google Photos give you the short version without installing anything.
When a credential validates, read who signed it. The signer is the claim, and the signer’s position in the trust list is what you are really being told.
When there is no credential, you have learned that the file does not carry one. That is the whole of what you know, and the specification asks you not to read more into it.