What an AI-generated PNG actually carries — and what a screenshot of it doesn't

A developer built a browser-based checker called Image or AI that reads C2PA Content Credentials and metadata client-side using @contentauth/c2pa-web (WebAssembly), after dissecting an OpenAI-generated PNG and finding a roughly 21 KB caBX chunk containing a C2PA manifest. The analysis showed the manifest's validation_state returned Invalid not because pixels changed, but because the signer's certificate was untrusted and missing the required extended key usage, and that a single re-encode with a stock tool like macOS sips stripped the manifest entirely. The developer argues Content Credentials prove origin when present but their absence proves nothing, and urges tools to show which evidence a verdict came from.

I generated one image with OpenAI's image model and then took it apart. The point wasn't the picture — it was to see what "proof this is AI" looks like inside a real file, and how fast it disappears. The PNG came out at 1536×1024. Besides the usual IHDR / IDAT / IEND chunks it had one extra: a caBX chunk of about 21 KB. That's a C2PA manifest — Content Credentials — stored in a JUMBF box. Reading it with the official Python binding: python import c2pa with c2pa.Reader "sample.png" as r: print r.json The interesting parts: OpenAI OpCo, LLC OpenAI Media Service API http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia That last field is the one that actually answers "was this made by generative AI?". The word trained matters: algorithmicMedia without it means procedural computer graphics, not a model. The overall validation state came back Invalid . My first instinct was "the signature is broken". It isn't. The per-check results tell a different story: claimSignature.validated — pass assertion.dataHash.match — pass pixels unchanged since signing timeStamp.validated — pass signingCredential.untrusted — fail signingCredential.invalid — fail "certificate missing required EKU" So the content and the claim are intact; what fails is whether the signer's certificate is on the C2PA trust list and carries the extended key usage the spec now requires. If you build anything on top of C2PA, report those two questions separately — "changed after signing?" and "trusted signer?" — or you'll tell users a genuine file was tampered with. One conversion with a stock image tool sips on macOS and the manifest was gone. strings on the JPEG found zero c2pa references. Same thing happens with a screenshot, and with most social and chat uploads, which re-encode everything. That's the uncomfortable part: Content Credentials prove origin when present, but their absence proves nothing. Most AI images you'll actually be asked about — in a group chat, a dating app, a refund dispute — have already lost them. The order that held up for me: I ended up building this order into a small browser-based checker, Image or AI https://imageorai.com/ , mostly because every detector I tried skipped straight to step 3 and never said what its answer was based on. Credentials and metadata are read client-side with @contentauth/c2pa-web WebAssembly , so the image doesn't leave the device for those steps. If you work with provenance data, the thing I'd most like other tools to copy is simple: show which evidence a verdict came from.