August 15, 2026

What Stable Diffusion, ComfyUI, and A1111 write into your PNGs

Drag a generated PNG back into ComfyUI and the entire workflow reappears — every node, every model, every slider value, exactly as you left it.

That's a genuinely great feature. It's also the whole problem. That workflow didn't come from a database or your browser cache. It was inside the PNG you posted, and it travels with the file to anyone who downloads it.

Most people generating images have no idea how much is in there.

Read your own file first

Before any of this is convincing, look at a PNG you've actually posted:

exiftool -a -G1 -PNG:all your_image.png

Or drop it into the image metadata viewer, which parses PNG text chunks in your browser without uploading anything.

You're looking for text chunks — tEXt (plain), zTXt (compressed), and iTXt (UTF-8). This is where every major Stable Diffusion interface stores its generation data.

Automatic1111 and Forge

A1111-lineage interfaces write a single tEXt chunk keyed parameters, containing one blob of text:

a photograph of a lighthouse at dusk, volumetric fog, 35mm
Negative prompt: blurry, watermark, text, extra fingers
Steps: 30, Sampler: DPM++ 2M Karras, CFG scale: 7,
Seed: 2847193056, Size: 832x1216,
Model hash: 6ce0161689, Model: v1-5-pruned-emaonly,
Denoising strength: 0.45, Clip skip: 2,
Lora hashes: "detail_slider: 7c6bad76eb",
Version: v1.10.1

Everything needed to reproduce your image, in plain text, inside the file. That's the design intent — it's what the WebUI's PNG Info tab reads, and what Civitai uses to auto-fill generation data when you upload.

Note Model hash and Lora hashes. Those identify the exact checkpoint and LoRAs you used, including private or purchased ones, by fingerprint rather than by name.

Saving as JPEG or WebP instead doesn't dodge this. PNG text chunks don't exist in those formats, so A1111 writes the same blob into the EXIF UserComment field. Different container, same payload.

ComfyUI writes considerably more

ComfyUI stores two JSON documents, typically as prompt (the API-format graph) and workflow (the full UI graph with node positions, titles, and notes).

The workflow chunk is the complete node graph. Not a summary — the graph. Every node, every widget value, every connection, every model filename, plus any notes you left yourself in the canvas. On a complex workflow this runs to tens or hundreds of kilobytes of JSON riding inside an image you thought was just pixels.

Three consequences worth sitting with:

Your whole method is public. If your workflow is your edge — a particular ControlNet arrangement, a multi-pass refiner setup, a custom node chain you spent weeks tuning — posting a raw ComfyUI PNG hands it over completely. Anyone can drag your image into their canvas and have your exact pipeline.

Local file paths can come along. Widget values are serialized as-is. Nodes that reference files by absolute path — image loaders, some custom nodes, video and batch nodes — can put strings like C:\Users\yourname\Documents\refs\... into the JSON. Your OS username, your folder structure, sometimes the names of unrelated reference images. This doesn't happen in every workflow, which is exactly why you should grep a real file rather than assume:

exiftool -b -PNG:workflow your_image.png | grep -oE '[A-Za-z]:\\[^"]{0,80}'

Notes are serialized too. Note nodes and renamed node titles are part of the graph. Anything you typed into the canvas as a reminder to yourself is in the file.

Why this matters beyond privacy

For anyone selling work, the prompt-and-seed exposure is a commercial problem more than a privacy one.

Prompt, seed, model hash, and sampler settings together make your output exactly reproducible. Not similar — identical. If you sell prompts, sell finished art, or take commissions, publishing a raw generation PNG gives away the product alongside the sample. People selling prompt packs have posted preview images containing the prompts they were charging for.

There's also a plain attribution angle. Some platforms and communities read these chunks to auto-label AI content. That may be entirely fine with you. It should still be your decision rather than a default you didn't know about.

What actually removes it

PNG text chunks live in the container, alongside the pixel data, never inside it. So anything that rebuilds the file from pixels alone drops them:

const canvas = document.createElement("canvas");
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;
canvas.getContext("2d").drawImage(img, 0, 0);
canvas.toBlob(blob => { /* no tEXt, no workflow, no prompt */ }, "image/png");

The decoder reads IDAT into a bitmap and walks past tEXt, zTXt, and iTXt. A bitmap has nowhere to put a workflow, so re-encoding produces a file with none. That's the mechanism behind the metadata cleaner, and it runs locally — no upload, so no server sees your prompts either.

Some approaches that don't work reliably:

Verify, don't trust

Whatever you use, check the output. On a cleaned file:

exiftool -a -G1 -PNG:all clean.png

You should see dimensions, bit depth, color type, and nothing resembling a prompt or a JSON graph. Run it on a dirty file first to confirm your check actually detects chunks that are definitely there — a test that can't fail isn't a test.

For ComfyUI specifically, the fastest sanity check is behavioural: drag the cleaned PNG onto your canvas. If nothing loads, the workflow is gone.

What this doesn't touch

The short version

A1111 writes your prompt, seed, sampler, and model hash into a parameters text chunk. ComfyUI writes your entire node graph, which can include notes and absolute file paths. Both survive re-uploads to any host that doesn't re-encode. Read one of your own posted PNGs before deciding whether you care — most people are surprised, and it takes ten seconds.

Related: what ChatGPT and DALL·E embed for hosted generators, and which platforms strip EXIF for what survives an upload.