DALL-E 3 metadata explained: C2PA manifests and JUMBF boxes

Images generated by modern artificial intelligence systems generally carry embedded provenance data known as C2PA Content Credentials. Because model providers frequently alter their export pipelines and image-handling configurations without public notice, NoWatermark has not tested specific provider outputs for current generation runs; the only reliable method to know what your image contains is to inspect the file directly.

Understanding what is inside an image file requires examining the technical mechanisms that carry metadata. Rather than relying on assumptions about how any particular platform exports assets, this guide explains how C2PA manifests are structured, how different container formats store them, why metadata is fundamentally distinct from server records, and how file inspection works in practice.

What C2PA metadata is and how it is structured

The primary standard used across the industry for AI provenance is developed by the Coalition for Content Provenance and Authenticity (C2PA). When an image generator produces an asset, it can embed a signed provenance manifest directly into the container. This manifest records contextual assertions about the file, such as the digital signing identity, the generation software, and standard metadata declarations.

A key field often found within these manifests is the IPTC DigitalSourceType value trainedAlgorithmicMedia. This standard tag explicitly signals to downstream software, search engines, and content registries that the media asset was created by a generative model rather than captured by a camera or drawn manually.

Crucially, a C2PA manifest is ordinary file metadata. It is a structured payload of bytes packaged alongside the image data inside the file wrapper. Because it exists purely as container-level metadata, it can be detected, parsed, and removed. When an application removes this metadata, the removal can be confirmed by re-scanning the cleaned file.

However, metadata must never be confused with the visual content itself. Modifying or stripping a manifest does not rewrite pixel values, nor does it interact with any external logging infrastructure.

Container storage: JUMBF boxes across JPEG, PNG, and WebP

To store structured provenance data without breaking compatibility with standard image viewers, C2PA relies on the JPEG Universal Metadata Box Format (JUMBF). JUMBF organizes information into discrete, typed boxes nested inside a superbox structure.

Different image file formats accommodate JUMBF boxes using their own native encapsulation mechanisms:

Format	Storage mechanism	Description
JPEG	APP11 application marker segment	Dedicated application segments embedded within the JPEG header stream.
PNG	caBX ancillary chunk	A four-character typed chunk dedicated to carrying JUMBF data without affecting rendering.
WebP	Dedicated metadata chunk	A standardized chunk payload defined within the Extended WebP file header structure.

Because these storage locations are modular segments of the container, standard image decoders simply skip over them when rendering the picture. A dedicated scanner, however, parses the byte stream to identify the presence of the JUMBF superbox, locate the manifest description box, and extract the readable provenance assertions.

When inspecting these formats, the tool reads the raw byte layout. When cleaning an image, the software drops these specific metadata chunks and segments entirely while copying the compressed image data byte for byte. This ensures that the container is rewritten cleanly without recompressing the picture or altering its visual quality.

Why NoWatermark reports presence rather than validity

When inspecting an image with the C2PA checker, it is essential to distinguish between detecting a manifest and verifying a cryptographic signature.

A complete cryptographic verification of a C2PA manifest requires validating the full digital certificate chain against trusted certificate authorities, checking revocation lists, and confirming cryptographic hashes across every asserted asset ingredient. NoWatermark runs entirely within your browser for privacy and speed, operating locally without sending files to an external verification service.

Because of this architectural design:

1. NoWatermark detects the presence of the C2PA manifest within the file’s JUMBF boxes.
2. It reads and parses the structural fields, extracting human-readable assertions and tags such as trainedAlgorithmicMedia.
3. It reports the manifest status strictly as present, never as valid.

Reporting a manifest as valid without full certificate authority validation would create an inaccurate sense of certainty. By reporting structural presence, the scanner provides a fact-based assessment of the file’s actual byte contents.

The three layers: metadata, pixel watermarks, and server provenance

Discussions around AI image tracking often conflate fundamentally different technologies. To understand what happens when you inspect or clean an image, you must separate attribution into three distinct layers:

+-------------------------------------------------------------------+
| 1. Container Metadata (C2PA, IPTC, EXIF)                          |
|    - Stored in file headers (APP11, caBX, WebP chunks)            |
|    - Detectable and removable; confirmed by re-scanning           |
+-------------------------------------------------------------------+
| 2. Pixel and Statistical Watermarks                               |
|    - Embedded mathematically within raw pixel values              |
|    - Permanent; status is permanently "unable to verify"          |
+-------------------------------------------------------------------+
| 3. Server-Side Provenance                                         |
|    - Maintained in provider databases and generation logs         |
|    - Completely external; no local file operation can touch it    |
+-------------------------------------------------------------------+

1. Container metadata

Metadata consists of headers, chunks, and tags—including C2PA manifests, EXIF records, IPTC declarations, and XMP packets. These structures reside entirely within the file wrapper. They can be detected by tools like the AI watermark checker and stripped using an AI metadata remover. Removal is verifiable because the output file can be scanned a second time to confirm the byte segments no longer exist.

2. Pixel or statistical watermarks

Pixel-level watermarks alter colour values or mathematical relationships across pixels during image synthesis. Because these signals are integrated directly into the uncompressed picture data rather than stored in separate metadata fields, their presence cannot be reliably established or disproved through client-side file inspection. The status of such statistical or pixel-level signals is permanently unable to verify. No local cleaning tool can guarantee their absence or certify human creation.

3. Server-side provenance

When you generate an image using a commercial platform, the provider creates an internal record linking the prompt, account ID, timestamp, and generated output hash within their private database. This server-side provenance exists independently of the exported file. Stripping metadata from a downloaded copy modifies only your local file; it has no mechanism to access, alter, or delete records stored on the provider’s servers.

Metadata fragility: why missing manifests prove nothing

Metadata is inherently fragile. It survives only as long as an application or platform explicitly chooses to preserve the container’s ancillary chunks.

In everyday use, image metadata is routinely stripped by routine operations:

• Social media uploads: Most publishing pipelines re-encode uploaded images to save bandwidth, discarding all non-essential headers, EXIF tags, and C2PA segments in the process.
• Image editing programmes: Exporting an image for the web or saving it under a different format frequently drops unfamiliar metadata boxes.
• Screenshots and screen captures: Taking a screenshot creates a new raster image from the display buffer, capturing only raw pixels and zero original metadata.
• Messaging platforms: Many chat applications compress and re-wrap images before transmission, stripping metadata by default.

Because metadata is so easily lost during standard digital distribution, the absence of a C2PA manifest or provenance tag is not evidence that an image was created by a human. An AI-generated image that has been passed through a compression script or shared via an online messaging platform will often show zero metadata, despite originating from an AI model.

Treating metadata inspection as a definitive test of authorship is a flawed assumption. Metadata tells you what is currently written in the file container; it does not guarantee the complete historical lineage of the visual content.

Inspecting and cleaning image files in the browser

If you need to verify what metadata is attached to an image, you can inspect it directly using client-side tools. NoWatermark operates entirely within the browser:

• No file uploads: Files are never transferred across the network. There is no upload endpoint, no remote database, and no server-side storage.
• Lossless metadata removal: When stripping metadata, the cleaner rewrites the container wrapper and copies the compressed image stream byte for byte. No decoding or recompression occurs, preserving the original visual fidelity.
• Two-pass verification: A removal is only reported after the resulting output file is parsed a second time and diffed against the original structure.
• Format coverage: The browser engine inspects and cleans JPEG, PNG, WebP, SVG, and Markdown files. (PDF files are supported for inspection only and are not modified).

To review the exact chunk types and metadata segments parsed across each supported file type, consult the comprehensive capability matrix at /capabilities.

For anyone working with AI-generated assets, the most practical approach is straightforward: never rely on generalised claims about what a platform embeds. Inspect your specific files with the ChatGPT watermark checker or C2PA checker, examine the extracted fields, and strip container metadata when privacy or workflow requirements call for a clean file.