AI Image Metadata: What It Reveals and What Removal Cannot Hide

When an AI image tool exports a file, the result may carry more than pixels. Prompts, model references, sampler settings, and even node graphs can sit in structured metadata containers next to the compressed image data. Those fields can be useful for reproducing a workflow, but they can also reveal creative decisions that were never meant for the recipient.

Not every AI-generated image contains those fields, and finding them does not prove how an image was made. The right approach is to inspect the file, interpret the evidence conservatively, and understand what metadata removal cannot change.

Where AI workflow metadata lives

Generation tools do not use one universal metadata format. Depending on the application, version, export type, and user settings, workflow data may appear in:

• PNG text chunks, commonly tEXt, zTXt, or iTXt entries.
• EXIF comment or description-style fields in some JPEG exports.
• XMP blocks that can travel with JPEG, PNG, or WebP files.
• Other supported metadata structures used by a particular exporter.

These containers are separate from compressed pixel data. For supported JPEG, PNG, and static WebP files, the homepage cleaner removes supported metadata containers without decoding or re-encoding that compressed image data. It creates a new copy and re-scans the output.

Common field families

AI workflow exports may include:

• A positive prompt and negative prompt.
• Seed, sampler, step count, CFG scale, or scheduler values.
• Checkpoint, model, or model-hash references.
• LoRA references and weights.
• Node graph or workflow JSON.
• Software and tool version strings.
• Editing history written during later post-processing.

These values are workflow evidence. They do not prove that a file was generated by AI, identify a person, establish copyright ownership, or validate authenticity. An image can lose this metadata during export, screenshotting, optimization, or platform processing. A non-AI editor can also create software, XMP, and history fields that look superficially similar.

ComfyUI

ComfyUI PNG exports can contain two substantial JSON structures:

• A prompt object describing an executable node graph.
• A workflow object preserving the visual graph and interface layout.

Depending on the workflow, these structures may expose node types, model or LoRA references, seeds, samplers, text inputs, and graph connections. They can also be large enough to reveal far more than a short prompt field.

The Image Metadata Viewer has dedicated local parsing rules for ComfyUI prompt and workflow JSON. This behavior is covered by a licensed public ComfyUI export in the committed real-file corpus, not just a hand-written string fixture. The public test evidence describes the broader corpus boundary.

AUTOMATIC1111

AUTOMATIC1111, also known as Stable Diffusion WebUI, commonly writes a structured plain-text block called infotext into a PNG text field named parameters. Depending on settings and version, the block may include:

• Positive and negative prompts.
• Steps, sampler, CFG scale, and seed.
• Model name or hash.
• Size and other generation parameters.

The scanner uses dedicated rules for this format rather than treating the entire field as an opaque comment. Coverage is backed by a licensed public AUTOMATIC1111 export in the committed real-file corpus.

InvokeAI and the evidence boundary

InvokeAI serializes workflow information as JSON, and the layout has changed across versions. The scanner contains rules for current and legacy InvokeAI-style metadata, including documented prompt, seed, model, scheduler, and step fields.

The evidence level is intentionally stated differently here. InvokeAI is covered by format-level unit tests based on documented serialization fields. The repository does not currently contain a committed real image exported by InvokeAI. ComfyUI and AUTOMATIC1111 therefore have real-file corpus evidence, while InvokeAI currently has format-rule evidence. That distinction matters when judging how broadly a parser has been exercised.

XMP and ordinary editing history

XMP is not an AI-specific signal. Conventional tools such as Photoshop, Lightroom, GIMP, and Affinity Photo can write software names, version strings, Dublin Core descriptions, rights fields, and editing history into XMP.

A CreatorTool field or an xmpMM:History entry may only mean that someone cropped, exported, or color-corrected a file. Read the field in context rather than turning a software string into an attribution claim. The Image Metadata Viewer groups recognized fields so you can inspect the original evidence before deciding what to remove.

The separate Image Metadata Editor follows a different workflow. It re-encodes a new image, discards the old metadata containers, and writes only five user-entered Dublin Core XMP fields: Title, Description, Creator, Copyright, and Keywords. It is not the homepage's lossless container-strip path.

C2PA and Content Credentials are a separate layer

C2PA Content Credentials are provenance data, not ordinary prompt metadata. A credential can include a cryptographically signed manifest that records assertions about creation or editing, commonly stored through JUMBF structures. The C2PA specification defines that system.

The current browser scanner performs conservative C2PA/JUMBF marker detection. It does not cryptographically validate a Manifest, confirm the signer, or fetch a remote Manifest. If a possible marker is found, removal pauses for explicit consent. The output can report that the supported marker was removed, but the provenance conclusion remains unverified.

Marker presence is therefore not proof of a valid Content Credential, and marker absence is not a statement about every possible provenance system.

A safe inspect, clean, verify workflow

1. Inspect the original. Open it in the Image Metadata Viewer. Review prompt, workflow, software, rights, and provenance groups before changing anything.
2. Decide what the evidence means. A prompt or node graph may be sensitive workflow data. A generic XMP software tag may only record a normal edit.
3. Clean a new copy. Use the homepage tool for supported JPEG, PNG, or static WebP files. It accepts up to five images, with a 25 MB limit per file, and never overwrites the original.
4. Handle provenance deliberately. If a possible C2PA/JUMBF marker is detected, read the consequence notice before consenting to removal.
5. Review the output re-scan. Confirm what was removed, preserved, unsupported, or could not be verified.
6. Use an independent reader when needed. Sensitive publishing or client delivery may justify a second metadata tool and a second reviewer.

The browser tool does not send selected file bytes, file names, metadata values, or hashes to a processing API. Page analytics may exist, but GA4 is disabled when a local file is selected, dropped, or pasted.

What metadata removal cannot do

Container stripping is useful, but it has a precise boundary:

• Pixel-level watermarks and SynthID are part of the image signal, not ordinary metadata containers.
• Steganographic payloads may be hidden in pixel values or other unsupported structures.
• Visual classifiers and perceptual hashes operate on image content.
• Platform-side inference may combine visual patterns, account history, upload context, or private systems.
• Copyright and provenance facts do not disappear merely because a descriptive field was removed.

Removing metadata does not make an image undetectable, prove that it was not AI-generated, or guarantee that a platform will not label it. The tool must not be used to misrepresent authorship, ownership, or provenance.

Pre-share checklist

• [ ] Inspect the file for prompts, negative prompts, seeds, models, LoRA references, and workflow graphs.
• [ ] Distinguish direct workflow fields from ordinary XMP software or editing history.
• [ ] Note whether the evidence comes from a real exported file or only a known format rule.
• [ ] Review any C2PA/JUMBF warning before deciding whether to remove a marker.
• [ ] Clean a new copy and inspect the output re-scan.
• [ ] Remember that pixel watermarks, classifiers, perceptual matching, and platform inference are unchanged.
• [ ] Keep the original and avoid using metadata removal to misrepresent the file.

Metadata removal is a privacy and information-hygiene step. It clears supported embedded text and structured data. It is not an AI detection bypass or a way to erase an image's history. Browse more evidence-led references in the guides hub.