Image provenance, C2PA and what metadata can actually prove
What Content Credentials are, what they are not, and the offline signals worth checking on any image before you publish it.
ES6 QA AI editorial · 30 September 2026 · 7 min read
What C2PA actually is
The Coalition for Content Provenance and Authenticity publishes a specification for attaching a signed manifest to a media file. In practice it means an image can carry a cryptographically signed record of who created it, with what tool, and what edits were applied afterwards. Adobe, Google, Microsoft and several camera makers ship support.
The useful part is the signature: a manifest claims an origin and can be verified against a certificate. The useless part is the assumption that its absence means anything. Most publishing pipelines strip metadata, and most social platforms rebuild files on upload. A file with no manifest is unproven, not forged.
Signals you can read offline
Without a network call you cannot validate a signature, but you can find out a great deal from the bytes and the pixels. This is what the offline checker does.
- Presence of a C2PA or Content Credentials block in the file header, which tells you a manifest exists and is worth verifying properly.
- Tool names written into XMP or EXIF: Firefly, Midjourney, DALL·E, Stable Diffusion, ComfyUI, Photoshop. A disclosure signal, not a defect.
- Colour profile and editing history, which reveal a professional pipeline — useful when a stock image claims to be a phone photo.
- Resolution against claimed use: a 480px image presented as a hero asset has been through at least one lossy round trip.
- Edge detail and compression density, which show whether a file was upscaled from something smaller.
- Blank or near-uniform frames, which are almost always a failed generation rather than a design choice.
What metadata cannot tell you
It cannot tell you whether the subject consented, whether the scene is real, or whether the depiction is fair. Every generative model can produce a convincing photograph of an event that never happened, and no manifest makes that image trustworthy — it only makes its origin legible.
It also cannot survive a hostile pipeline. Metadata is trivially removed. If provenance matters to you legally, the record has to live somewhere the file cannot be stripped of: your own audit trail, tied to a hash of the original.
A practical publishing rule
Keep the original file, record its hash and where it came from, and attach that record to the deliverable. Then decide, per use, whether the image needs a disclosure. For a product mock-up, usually not. For anything depicting a real person, a real event or a real product capability, assume it does.
And when an image carries a named generative tool in its metadata, treat that as a fact about the file that someone will eventually find. Publish as if they already have.
These rules are the same ones the console runs. Check a file against them now.