How to Read a C2PA Manifest: A Field-by-Field Guide

Last updated: October 13, 2026 · 8 min read

By the Ingenious AI team

A C2PA manifest is the most useful disclosure artifact you'll ever handle, and one of the most intimidating to open. It's a JSON blob buried in the file's JUMBF box, full of nested assertions with names like stds.iptc and c2pa.actions. The first time I cracked one open, I closed the tab.

Here's the thing: you only need to understand five sections. Once you can read those, a manifest tells you the whole life story of a file. And unlike a platform checkbox, it travels with the file, which is exactly why platforms like Meta read these industry-standard indicators from uploaded files when deciding whether to attach their own "AI info" labels.

First, get the manifest out of the file

You don't need special software. The quickest free option: drag the file into verify.contentauthenticity.org and click "inspect." That gives you the human-readable version, fine for a one-off check.

For programmatic access, the open-source c2patool CLI dumps the manifest as JSON with one command:

c2patool image.jpg --manifest > manifest.json

That's what we parse under the hood in DisclosureGuard. One of the first things we learned building the parser is that real-world manifests are messier than the spec: optional fields everywhere, tools that each sign things slightly differently, and manifests written by older tool versions that predate half the assertion types. The spec is clean. The field is not.

Once you have the JSON, look for these five sections.

1. The claim generator, "who wrote this manifest?"

Find claim_generator_info. It names the software that created the claim, plus a version string. This is your first signal:

"Adobe Firefly": image (or parts of it) came from Adobe's generator.
"Photoshop" with version 25.x, edited in a C2PA-aware Photoshop build.
"c2patool 0.x": someone (or some pipeline) attached a manifest manually with the open-source tool.
A name you don't recognize, look it up; sometimes it's a legit pipeline tool, sometimes it's someone hand-crafting claims to look kosher.

The claim generator doesn't tell you what was done. It tells you whose handwriting you're reading. And handwriting matters: a claim generated by the camera or the editing app at creation time carries more weight than one attached afterward by a standalone tool, because the after-the-fact manifest is a statement about a file the tool didn't necessarily witness being made.

2. The actions assertion, "what happened to this file?"

Find the assertion labeled c2pa.actions. It's a list of everything the claiming tool says it did. The action names that matter most:

c2pa.created: the file was created by this tool. Combined with a generator name like Firefly, this is the smoking gun of AI generation.
c2pa.generated, AI-generated content was introduced. This is the one that should make your disclosure reflex fire.
c2pa.edited: human or tool edits; look at the nested softwareAgent and any parameters for detail.
c2pa.repackaged: the file was re-encoded (format change, resize). Benign on its own, but watch for it without earlier actions: it can mean someone re-exported a file to shed an inconvenient manifest.

Honest caveat: actions are self-reported. A manifest is a signed statement by the software, not an independent audit. A bad actor can lie in a manifest. What they can't do, without breaking the signature, is edit someone else's manifest. Keep that asymmetry in mind: the manifest proves the file wasn't altered after signing, not that the signer told the truth.

3. The ingredients, "what went into this?"

Find the ingredients array. Each ingredient is a source asset the file was built from, with its own thumbnail and sometimes its own embedded manifest (nesting dolls). This is where composite images tell on themselves.

Here's a constructed example of the pattern we see in testing: a product lifestyle shot whose c2pa.actions only says edited, but whose ingredients list three sources: a studio photo of the product, a stock beach photo, and a Firefly-generated sky. The actions said "edited." The ingredients told the real story: the sky was synthetic, and the visible "photo" was two-thirds borrowed, one-third generated. Ingredients are the section people forget to check, which is exactly why they're the section worth checking.

The practical habit: when the actions look clean, read the ingredients before you clear the file. Composites are where disclosure failures hide, the final file looks like one photo, and the manifest's ingredient list is the only place that says otherwise.

4. The hash, "has anything changed since signing?"

Each assertion block carries a c2pa.hash.data entry naming the algorithm (usually sha256) and the hash of the asset the manifest describes. If someone opens the file in an editor and re-saves it without updating the manifest, validation fails.

Validation has three outcomes, and people constantly misread the second one:

Valid: manifest intact, file unchanged since signing. This is the good outcome.
Invalid: something was altered after signing. Treat the manifest's claims as unreliable. Note: this does not mean the file is fake. It means the signature no longer matches, which happens with completely innocent re-saves too.
Missing signature: someone attached assertions without signing. Read them as a Post-it note, not a notarized document.

The most common cause of "invalid" we've seen isn't fraud. It's the export pipeline: the file leaves the editing app with a valid manifest, gets recompressed by a CMS or a social platform, and the manifest breaks. Which is why you validate the delivered file, not the working file, a manifest that was valid in the designer's folder tells you nothing about the version the audience sees.

5. The signature, "should I trust any of this?"

The c2pa.signature assertion binds the manifest to a certificate. The certificate's trust anchor is what matters: manifests signed with certificates in the C2PA trust list verify as "signed by a trusted issuer." Self-signed or unknown-issuer manifests verify structurally but carry no trust.

When we built DisclosureGuard's parser, this is where we spent the most time, because "signature valid" is the phrase everyone reads, and it's only meaningful if the issuer is one you recognize. A valid signature from an unknown tool proves the file wasn't tampered with. It proves nothing about what the tool claims. Trust the math, verify the issuer.

The 60-second manifest read

Once you've done it a few times, this is the whole routine:

Claim generator: who wrote this?
Actions: what did they do, look for generated.
Ingredients: what went into it?
Hash: is the file unchanged since signing?
Signature: is the issuer trusted?

Five questions, one minute, and you'll know more about a file's provenance than most of the people who handle it.

For video: check the frames, not just the file

For video, the manifest story gets one more chapter: frame-level manifests. Video files can carry provenance per segment, not just per file, which is how you catch the common trick of a 10-second AI-generated bumper spliced into an otherwise real 2-minute video. A whole-file manifest that says "edited" can hide a synthetic segment, but the frame data doesn't lie. Our scanner checks frames individually for exactly this reason.

The other video gotcha: most platforms transcode uploads aggressively, and transcoding is where manifests go to die. A video that leaves your editor with a pristine frame-level manifest can arrive on the platform with nothing. Verify what's embedded in the version that actually ships.

When the manifest lies, and what to do about it

Let's close with the uncomfortable part. Everything above assumes the signer is honest. A dishonest signer can write a clean-looking manifest claiming a fully synthetic image was "captured" by a camera. The signature will validate. The trust list will show the issuer. The lie is in the assertions, and no cryptography detects that.

So treat the manifest as one input, not the verdict. Cross-check against reality: does the claimed capture device match the image? Do the ingredients make sense? Is the claim generator consistent with the workflow the file supposedly went through? A manifest that says "captured on device X" attached to a file with Firefly in its history deserves a second look, and that second look is exactly what the ingredients section is for.

One more caveat, because it matters: C2PA is only as complete as the tools that write it. Plenty of generators still ship files with no manifest at all. Absence of a manifest tells you nothing, a file with no provenance could be a pristine camera capture or a fully synthetic render. Never read absence as innocence.

Quick FAQ

Do I need C2PA on everything I publish?
No. Prioritize: ad creatives (platform policies + Art. 50 exposure), anything photorealistic that could be mistaken for real, and client deliverables where provenance is part of what you're selling. A stylized graphic that nobody could mistake for a photo doesn't need a manifest.

Will a manifest survive uploading to Instagram or Facebook?
Usually not, the platforms re-encode uploads, which strips embedded metadata including manifests. That's why visible disclosure and platform-side controls still matter, and why you should test with our free drift check before assuming anything survives.

Is a valid signature proof the content is real?
No. It's proof the file is unchanged since an issuer signed it. "Real" is a claim about the world; the signature is a claim about the bytes. Keep the two separate.

Scan your first piece of content free →