How to read the prompt and settings from a Stable Diffusion image

You found an image you like, or one of your own from months ago, and you want the prompt that made it. Often the answer is already inside the file. Image generators tend to write their settings into the file as metadata, next to the pixels, where a viewer can read them.

This guide explains where each popular tool stores that data, how to read a settings block field by field, why it so often disappears, and how far you can trust (and reproduce) what you recover. To read a file right now, drop it into our image metadata viewer. It reads the file's metadata in your browser and splits the prompt, negative prompt and settings into separate, copyable fields.

Where generation settings are stored

A PNG file is a sequence of chunks. Pixel data lives in the image chunks, and the format also allows text chunks, each holding a keyword and a string. That is the easiest place for a tool to put a prompt, so most do. JPEG and WebP have no text chunks, so tools use their EXIF or XMP metadata instead. The common layouts look like this:

These names come from each project's source code, which you can read yourself: AUTOMATIC1111's web UI and InvokeAI are both open source. Formats can change between versions, so treat the table as a map, not a promise.

The AUTOMATIC1111 parameters block

The Stable Diffusion web UI by AUTOMATIC1111 introduced the layout that most people mean by "PNG info", and many forks and other tools write the same one. It has up to three parts: the prompt, an optional Negative prompt: line, and one final line of comma-separated settings that starts with Steps:. Here is an invented example, written for this guide and not taken from a real file:

a quiet mountain lake at dawn, low mist, pine forest, soft light, photograph, <lora:mist_style:0.6>
Negative prompt: blurry, low quality, watermark, text, oversaturated
Steps: 28, Sampler: DPM++ 2M, Schedule type: Karras, CFG scale: 7, Seed: 1203948576, Size: 768x512, Model hash: 1a2b3c4d5e, Model: example_model_v1, Denoising strength: 0.45, Hires upscale: 2, Hires upscaler: Latent, Lora hashes: "mist_style: 9f8e7d6c5b", Version: v1.10.1

Reading the last line field by field:

• Steps, Sampler, Schedule type, CFG scale: how the image was denoised and how strongly it followed the prompt. Older files often fold the schedule into the sampler name, such as DPM++ 2M Karras.
• Seed: the starting noise. The same seed with different settings gives a different picture.
• Size: width and height. When hires fix is on, this is the size of the first pass. The final image is larger.
• Model hash and Model: which checkpoint was loaded. The hash is the first ten hexadecimal characters of the checkpoint file's SHA-256, so it identifies the exact file even if someone renamed it.
• Denoising strength, Hires upscale, Hires upscaler: second-pass (hires fix) or image-to-image settings.
• Lora hashes: short hashes for the LoRAs named in the prompt's <lora:name:weight> tags. The value contains a colon, so the web UI wraps the whole thing in quotes. Values that contain commas, colons or line breaks get the same treatment.
• Clip skip, ENSD, RNG, Version: optional fields. Clip skip is only written when it is above 1, and RNG only when it is not the default GPU source. Extensions add their own entries to the same line.

No two files look exactly alike, because the settings line contains whatever the app and its extensions report. A parser has to find the last line that begins with Steps: and treat everything above it as prompt text. The web UI has a PNG Info tab that reads these blocks, and the viewer does the same for many files at once.

ComfyUI: the prompt and workflow chunks

ComfyUI saves two JSON documents. The workflow chunk is the full editor graph, including node positions and links, so the interface can rebuild your canvas. The prompt chunk is the stripped-down version the server actually executes, usually called API format. ComfyUI's documentation says dragging a generated image onto the canvas, or using File, Open, restores the graph when the workflow field is present.

The prompt text is not stored as a sentence. It sits inside the graph, as the text input of a text-encoding node. The settings sit in the sampler node. A shortened, invented example of API format shows how to find the positive and negative prompts:

{
  "3": {"class_type": "KSampler", "inputs": {"seed": 8675309, "steps": 20, "cfg": 7, "sampler_name": "euler", "scheduler": "normal", "denoise": 1,
        "positive": ["6", 0], "negative": ["7", 0], "model": ["4", 0], "latent_image": ["5", 0]}},
  "6": {"class_type": "CLIPTextEncode", "inputs": {"text": "a red bicycle leaning on a brick wall", "clip": ["4", 1]}},
  "7": {"class_type": "CLIPTextEncode", "inputs": {"text": "blurry, low quality", "clip": ["4", 1]}}
}

A pair such as ["6", 0] means "output 0 of node 6". Follow the sampler's positive link and you land on the positive prompt. A viewer can only guess from node order which text node is which, so when a graph has more than two text nodes (regional prompts, refiners, upscale passes), open the workflow in ComfyUI and follow the wires. The same documentation notes that this metadata does not include the models, inputs or custom nodes a workflow needs, and that it should be treated as optional, untrusted input.

NovelAI: the Comment field and hidden alpha data

NovelAI PNGs normally carry Software set to NovelAI, the prompt in Description, and a JSON Comment with fields such as uc (the negative prompt, which NovelAI calls undesired content), steps, scale, seed and sampler. This is the layout AUTOMATIC1111's own import code reads.

NovelAI's open-source metadata tools document a second copy, often called stealth metadata. Instead of a text chunk, the data is hidden in the alpha (transparency) channel: the lowest bit of each pixel's alpha value is read column by column, and the bits spell a short marker, a length, and gzip-compressed JSON. Some community extensions for other image tools offer a feature with the same goal under the name stealth PNG info. The point is that it survives when a site removes text chunks. The limits are strict, though. It only exists in lossless PNG files, and a change that alters the pixels or drops the alpha channel typically destroys it. Our viewer decodes this format as well.

InvokeAI, Fooocus and web services

InvokeAI writes its own text chunks, so a tool that only knows the parameters layout shows nothing for it. Fooocus can write either a JSON or a web-UI-style parameters chunk, and records which in fooocus_scheme.

Hosted services are a different story. Midjourney, for example, documents a hidden ID tag in the images it delivers and offers a checker at midjourney.com/verify, but its documentation does not describe a prompt field in the file. Some web services put the prompt in a plain description field, and some put nothing at all. If your file has such a field, the viewer shows it. If it does not, the prompt is not in the file, and the place to look is your account's job history. Midjourney's documentation describes copying the prompt and job ID from its website.

Why the metadata is missing

If you open an image and find nothing, one of these is almost always the reason:

• It is a screenshot. A screenshot is a brand-new image with new pixels and no history.
• It was re-saved or converted. Many editors, resizers and converters write a fresh file and carry over only some metadata. Converting PNG to JPEG or WebP usually drops text chunks.
• A website re-encoded it. Plenty of sites recompress uploads and discard metadata. Behavior differs by site and changes over time, so test with one image before you rely on it.
• The generator was told not to save it. The web UI has a setting named "Write infotext to metadata of the generated image", and ComfyUI has a --disable-metadata start-up flag. The web UI can also write the same text to a separate .txt file next to each image, so check the output folder.
• Someone removed it on purpose. People strip prompts before sharing. A metadata remover such as our image metadata remover deletes text chunks, EXIF, XMP and Content Credentials without re-encoding the pixels. That is useful if you want to share a picture without your prompt and settings.

A missing prompt tells you nothing about how the image was made. A prompt that is present is only a claim, because anyone can type text into a metadata field. For the wider question of what metadata can and cannot prove, see our guide to Content Credentials and watermarks.

Reproducing an image from the recovered settings

Copying the prompt, seed and settings into the same program gets you close to the original. It does not always give you the same pixels. These are the things that have to match:

• The exact model files. Compare the model hash and Lora hashes against the files you have. A renamed file with the same hash is fine. A model of the same name at a different version is not.
• Every setting on the line, including hires fix, clip skip and any extension settings, plus the prompt text with its emphasis syntax and LoRA tags.
• The random number source. The web UI's own help text for its RNG option says that changing it changes seeds drastically, and that the CPU source is for getting the same picture across different graphics card vendors.
• The software version. The web UI's wiki page on seed-breaking changes lists updates that make an old seed render differently, and most come with a compatibility option to restore the old behavior. PyTorch's documentation likewise says completely reproducible results are not guaranteed across releases, commits or platforms.

Metadata also leaves things out. Image-to-image inputs, inpainting masks, ControlNet reference images and custom nodes are not stored in full, so an image made with them cannot be rebuilt from the text alone. If you need the exact result, keep the original file. If you only need a similar one, the recovered prompt and settings are an excellent starting point.

Reusing prompts, and giving credit

A recovered prompt is a good way to learn how a style was built, and it makes a decent first draft of your own. It describes what the author asked for, not what the picture shows, so it is a poor caption for training data. If you are preparing a dataset, tag or caption the images themselves. Our guides to LoRA dataset captions and tags versus natural-language captions explain how.

If the image is someone else's, the prompt was part of their work. Crediting them when you share results, and checking the license of the site and models involved, is a considerate habit. This is general etiquette, not legal advice. More free image tools are listed on our tools page.