c2pa.assael.io

Who signed this image?

A C2PA-signed image carries a manifest: a tamper-evident record of where the image came from, cryptographically signed by a certificate. The CA pin is the badge that answers the only question that really matters — which certificate authority vouched for it, and do we trust them?

These three pages read the same signed images and surface that answer three different ways, from hand-rolled to no frontend code at all.

aThe Content Credentials pin

Real camera captures with the pin overlaid on the photo, as the CAI specifies it. Click the pin for the issuing authority, the capture device, and the signing time.

bFull manifest inspector

The same SDK, taken all the way: every manifest in the store, every assertion, the ingredient chain, and each individual validation check.

cHand off to Verify

No SDK, no WebAssembly, no badge design. Deep-link each image into Adobe's hosted Verify tool, or embed it in an iframe. Zero frontend work.

Valid is not the same as trusted

Reading a manifest yields one of three states, and conflating the first two is the most common mistake in a Content Credentials UI:

Trusted — the signature is intact and the issuing CA is on the C2PA trust list.
Valid — the signature is intact, but the issuer is unrecognised. Anyone can mint a certificate and sign an image with it.
Invalid — a signature or content hash failed. The credential asserts nothing.

A green check that means only "the bytes match the signature" is close to worthless: it says the image hasn't changed since somebody signed it, not that the somebody is who they claim to be. That's why the pin names an issuer.

The images are real

No synthetic fixtures signed with throwaway test certificates. Every image here was signed by the thing that made it, with a production certificate:

Phone camera — an Android capture signed on-device by Truepic's controlled-capture camera, chaining to Truepic RootCA, which is on the C2PA trust list.
Nikon Z-series — a real in-camera signature from Nikon's 2022 pilot. Instructive precisely because its chain predates Nikon's entry on the trust list, so it reads Valid rather than Trusted.
Adobe Firefly — no camera at all: generated from a prompt, and the manifest says so.
Leica M11-P → Photoshop — signed in-camera, then edited and countersigned, leaving two stacked manifests and the original as an ingredient.

Why no Google Pixel 10. The Pixel 10 camera does write Content Credentials, but Google has not published a Pixel 10 original at a stable URL — the images on their blog and store are re-encoded, which strips the manifest. Beyond that, no Google root is currently on the C2PA trust list, so even a genuine Pixel capture would read as Valid rather than Trusted. If you have a Pixel 10, send me an untouched original and it goes on the page.

How it's built

Demos (a) and (b) use @contentauth/c2pa-web, the maintained browser SDK — WebAssembly bindings over the Rust c2pa-rs library. It's loaded straight from a CDN as an ES module; there is no build step anywhere in this site. The older c2pa and c2pa-wc packages are deprecated in its favour and are not used here.

Because the browser must read the image bytes to check the signature, the image host has to permit cross-origin reads. Most do not: Leica serves its sample without an Access-Control-Allow-Origin header, so that one is mirrored here. The rest are fetched straight from the C2PA project's test-file repository.