1. Is there a C2PA manifest, and does it travel inside the file?
Everything the other nine checks look at lives in the manifest, so this one decides whether there is anything to examine. Embedded is what matters: a manifest hosted at a URL and merely referenced from the file is a marking that stops existing the moment the recipient is offline or the URL moves. This check also catches the case where a file was marked and later stripped — signing leaves a provenance reference in the XMP, and most strippers remove the manifest without removing that reference.
Worked example
You sign a 2048px JPEG and it passes. Your CDN then serves a resized copy, and the resize drops the APP11 segment the manifest lived in but keeps the XMP. The check now fails with “stripped”, because the pointer below is still in the file and the thing it points at is gone.
xmp:dcterms:provenance = "self#jumbf=c2pa/urn:uuid:8f2c…"
2. Does the signature over the manifest verify against its own certificate?
The signer hashes the claim — the manifest's list of assertions — and signs that hash. Verifying it proves the claim has not been edited since, and that whoever holds the certificate's private key produced it. Note what this does not cover: it says nothing about the image bytes (check 5) and nothing about whether the certificate is worth anything (check 3). A self-signed certificate produces a perfectly valid signature.
Worked example
Open a signed file in a hex editor and change trainedAlgorithmicMedia to digitalCapture inside the manifest. The pixels are untouched, so check 5 still passes — but the claim no longer hashes to what was signed, and this check fails.
3. Was the signing certificate issued by an authority C2PA recognises?
A valid signature only tells you the file was signed by whoever holds that key. This check asks whether anyone outside your own stack has a reason to care who that is. The certificate has to chain to the official C2PA trust list; a self-signed one is fine for development and is worth nothing as evidence to a third party. It is weighted supporting rather than blocking because an untrusted certificate does not make the marking absent, only unattributable.
Worked example
samples/CACA.jpg in this repo is signed by “C2PA Test Signing Cert”, the development certificate that ships with c2pa-rs. Signature valid, trust list failed — exactly the shape an internal pipeline produces before anyone has bought a real certificate.
4. Is there proof of when this was signed, from someone other than the signer?
A signature is only verifiable while the certificate behind it is valid. An RFC 3161 timestamp authority counter-signs the signature with its own trusted clock, which fixes the signing moment in a way the signer cannot backdate. Without one, the manifest still records a time — but it is the signer's own clock, which is not evidence of anything.
Worked example
Your certificate is valid through 2027 and you sign in 2026. In 2028 a verifier sees a signature from an expired certificate and cannot tell whether you signed while it was valid or forged it afterwards. With a timestamp token, that same signature still verifies in 2035.
5. Do the bytes in this file still hash to what the manifest recorded?
At signing time a hash of the asset itself is written into the manifest. This check recomputes it. A match means the manifest describes these exact bytes; a mismatch means the file was altered after signing, and the marking no longer describes what you are looking at. It is also what stops a valid manifest being lifted off one image and attached to another.
Worked example
The most common way a working marking dies: sign at full resolution, then let an optimiser re-encode the JPEG on the way out. Every byte of the manifest survives and verifies — check 2 passes — and the hash no longer matches the pixels.
assertion.dataHash.mismatch
6. Does the manifest actually say the content is AI-generated?
This is the Article 50(2) question, and the reason this tool exists. A manifest records actions; each action may carry a digitalSourceType from the IPTC vocabulary. Only the trained-algorithmic-media family reads as “artificially generated” to a detector. A manifest can be present, signed, trusted, timestamped and byte-perfect while being completely silent on this — and every general-purpose C2PA verifier will show it a green tick.
Worked example
The assertion below is what a passing file carries. Delete the digitalSourceType line and the manifest is still entirely valid, still verifies, still chains to a trusted certificate — and no longer says a model made the image.
"label": "c2pa.actions",
"data": { "actions": [ {
"action": "c2pa.created",
"digitalSourceType":
"http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia",
"softwareAgent": "Acme Diffusion v3"
} ] }
7. Does the manifest name what produced the content, not just who signed it?
Two different fields answer two different questions, and they are routinely confused. claim_generator_info names the tool that wrote and signed the manifest. softwareAgent on the generating action names the system that made the content. They are often not the same party, and a marking that names only the first tells an authority who to ask, not what to ask about.
Worked example
A newsroom signs an illustration a model vendor generated. The claim generator reads “NewsCorp Publishing Tool 2.1” — that is the signer. The softwareAgent on the c2pa.created action reads “Acme Diffusion v3” — that is the generator. Drop the second and the file records a publisher and no model.
8. For a composite, do the parts carry provenance of their own?
An asset built from other assets declares them as ingredients. Each ingredient may carry its own manifest, and the chain is only as informative as its weakest link: an ingredient with no manifest is a part of the image about which nothing is known, including whether it was AI-generated. Not applicable to a standalone asset, which declares no ingredients at all.
Worked example
A poster composites a licensed stock photograph with an AI-generated background. The stock photo arrives signed; the background arrives bare. The composite's own manifest can be flawless and still leave no record that half the picture came out of a model — which is what compositeWithTrainedAlgorithmicMedia exists to say.
9. Is the marking carried by anything other than metadata?
A manifest lives in a metadata segment, and metadata is the first thing platforms discard. A soft binding — a watermark or perceptual fingerprint declared in the manifest and recoverable from the pixels — is what lets a marking degrade instead of vanishing. This tool reports whether one is declared. It does not run a detector, so it cannot tell you a watermark is still recoverable from these particular pixels.
Worked example
Upload a marked image to almost any social platform and download it again: the re-encode strips the manifest completely and nothing is recoverable. This is a real gap in the ecosystem rather than a box you have failed to tick — which is why it warns rather than fails, and why it is weighted robustness.
c2pa.soft-binding
10. Does the C2PA spec define a place inside this file type for a manifest?
Embedding needs a defined location in the container, and the spec only names one for some formats. Where it does not, a marking has to travel beside the file as a sidecar or be fetched from a URL — and both are lost the moment the asset is copied, forwarded or uploaded on its own. This version is tested against JPEG, PNG, WebP and AVIF; other embeddable formats are reported as indicative.
Worked example
JPEG carries the manifest store in APP11 marker segments and PNG in a caBX chunk, so both survive an ordinary copy. BMP has no defined location at all: there is nowhere in the file to put the marking, whatever your signer supports.