isGenAI.com

Glossary

JUMBF: where a C2PA manifest physically lives

JUMBF (JPEG Universal Metadata Box Format, ISO/IEC 19566-5) is a container of typed boxes, borrowed from the ISO base media file format, that C2PA uses to store a manifest store inside JPEG APP11 segments, a PNG chunk, a WebP chunk, HEIF and MP4 boxes, TIFF tags and PDF.

Definitions and isGenAI behaviour as of October 2026. Updated .

See the term in a real reportFrequently asked questions
Controlled example PNG file that carries this record: Content Credentials found

test-signed.pngPNG file · controlled example

  1. Signature + IHDR
  2. iTXt XML:com.adobe.xmp
  3. tEXt parameters
  4. tEXt prompt / workflow
  5. tEXt invokeai_metadata
  6. eXIf
  7. caBX C2PA manifestrecord
  8. IDAT pixels
  9. IEND

Content Credentials found

A signed manifest describes how the file was made.

Signer, recording tool, actions and the signature check result are reported separately, so you can weigh each one.

Open the Content Credentials checker →
Content Credentials found: where this record sits inside a PNG file and what the isGenAI report says about it. The picture is a code-drawn controlled example that carries this record; download it and check it yourself.

What JUMBF defines

JUMBF defines superboxes with a description box naming the content type by UUID and label, followed by content boxes holding JSON, CBOR, codestreams or embedded files. C2PA’s manifest store is a JUMBF superbox whose children are manifests, each with assertion, claim and signature boxes. Because JUMBF is container-agnostic, the same manifest bytes can be placed in a JPEG, a PNG or an MP4 with only the outer wrapper changing.

In JPEG the store is split across APP11 segments; in PNG it sits in a dedicated chunk; in ISO base media files it is a top-level uuid box.

How isGenAI uses JUMBF

The C2PA checker and AI image detector locate the JUMBF store in supported containers, parse the manifests and validate signatures and hashes. The report lists the manifest labels found, the active manifest’s claim generator and its assertions. If the JUMBF structure is present but damaged, the report says the record could not be validated rather than ignoring it.

Why the location matters

Tools that rewrite a file must copy the JUMBF store intact for the signature to survive, and most do not. That is why conversion, compression and platform uploads break Content Credentials even when they keep ordinary EXIF.

A single file can hold several manifests in one store, one per editing step. The order and labels inside the JUMBF superbox tell a validator which manifest is active and which are ingredients, which is how a chain of edits stays readable.

How to use this term when checking a file

  1. Upload the original file to the AI image detector or the tool named on the page.
  2. Find the finding that uses this term under “How we checked” and read the source field it names.
  3. Weigh it by kind: a signed record, a declared field, a saved prompt and a matching copy are different strengths of evidence.
  4. Remember that absence of a record is not evidence of a human author.

See the term in a real report

Frequently asked questions

Is JUMBF the same as C2PA?

No. JUMBF is the box format; C2PA defines what goes in the boxes. A C2PA manifest store is one use of JUMBF.

Which formats carry JUMBF?

JPEG (APP11), PNG (a dedicated chunk), WebP, HEIF, AVIF, TIFF, MP4, MOV and PDF, per the C2PA specification.

Can I see the JUMBF boxes myself?

The C2PA checker shows the parsed manifest labels and assertions; a hex viewer shows the raw boxes.

Does re-saving keep JUMBF?

Only in C2PA-aware tools. Most editors and all social platforms drop it.

Sources

Definitions follow the published standards linked above; the isGenAI behaviour described is the deployed checker as of October 2026.