ComfyUI runs image and video generation as a node graph, and it treats that graph as a first-class artifact. The documentation states that the workflow is automatically saved in the metadata of any generated image, so the graph that produced an image can be reopened from the file itself: drag a ComfyUI-generated PNG into the interface and the full node setup returns, with prompts, seeds, samplers, and wiring included. Workflows can also be exported as JSON files, which the documentation notes are small enough to make versioning, archiving, and sharing convenient. Among generation tools this is as close to self-documenting as it currently gets.
The limits are just as specific. The embedded workflow records what your nodes pointed at, not what they contained. The checkpoint name in a loader node is a filename on your disk, and the image cannot prove which weights that filename held on render day. Input images, masks, and reference material are referenced by the graph without being carried inside it, and workflows built on custom node packs only reopen on machines where the same packs are installed. The documentation itself notes that storing the workflow as a separate JSON file becomes necessary for media types that lack metadata support, which in practice covers much of the video work ComfyUI is increasingly used for.
Metadata is also fragile in ordinary hands. One conversion to JPEG for a client deck, one pass through an editor that rewrites files, and the embedded graph is gone with no visible change to the image. So the working rule for ComfyUI is simple: let the embedded workflow be the convenience, and let an exported JSON, the model identities, and the input files be the record. The checklist below makes that concrete.
What ComfyUI stores on its side
- The ComfyUI workflow is automatically saved in the metadata of any generated image, allowing the graph that produced an image to be opened again from the file itself. Source
- A workflow can be loaded by dragging a ComfyUI-generated image into the interface or through the Workflows menu, and workflows can be exported as JSON files. Source
- The built-in Save Image node writes PNG files to the ComfyUI output directory and can embed workflow metadata, such as the prompt, into the saved file. Source
- Workflows stored as JSON files are very small, which the documentation notes allows convenient versioning, archiving, and sharing of graphs independently of any generated media. Source
What gets lost without your own record
- The embedded workflow names the checkpoints, LoRAs, and input files your nodes loaded, but it contains none of them, so reproducing a render requires the same files on disk and the image alone cannot prove which files those were.
- Converting the PNG to JPEG, or passing it through an editor or platform that rewrites metadata, silently drops the embedded graph while leaving the image looking untouched.
- The documentation notes that a separate JSON file becomes necessary for media types lacking metadata support, so renders to formats without embedded metadata leave the output with no built-in record at all.
- Workflows that depend on custom node packs only reopen where those packs are installed, and the image metadata does not carry the packs or their versions.
- The graph records how a result was computed, never why. The brief, the client, the rejected branches, and the approval have no place inside ComfyUI.
The documentation checklist for ComfyUI
- Save deliverable images through the Save Image node, so the file that leaves the machine actually carries the workflow metadata.
- Export the workflow as JSON for every delivered final and store it next to the client file, because the JSON survives the format conversions that strip image metadata.
- Record the exact checkpoint, LoRA, and VAE files the graph loaded, with file hashes where you can, since the workflow stores the loader's filename and not the weights.
- List the custom node packs and versions the workflow depends on, so the graph can be reopened on another machine or after a rebuild.
- Archive every input image, mask, and reference the graph consumed, because the workflow references them without containing them.
- Note the ComfyUI version used for the render, and record which output the client approved and on which date, since neither exists anywhere in the graph.
ComfyUI gives a documentation-minded team a real head start: the recipe travels with the artifact by default, and a JSON export of the same graph costs nothing to keep. The gap between that and a delivery record is exactly the set of things outside the graph, which is the model files as they existed on disk, the inputs, the environment, and the human decisions. Teams that capture those things at render time can reproduce and defend their work in a way no hosted tool currently matches.
For EU-facing deliveries the same split applies to the transparency duties of Article 50 of the EU AI Act. The workflow shows how an output was generated, but the disclosure record, meaning what was published as AI generated, where, and when, still has to be kept by the team that ships the work. A record that pins the workflow JSON, the inputs, and the approved output to a date, and can show they have not changed since, covers what a client or a platform will actually ask to see.
Frequently asked questions
Can I recover the exact workflow from a ComfyUI image someone sent me?
If it is the original PNG saved by ComfyUI with its metadata intact, yes: drag it into the interface and the graph loads. If the file was converted, compressed, or re-saved along the way, the metadata is likely gone, which is why the exported JSON is the copy to trust.
Does the embedded workflow prove which model made the image?
It records the checkpoint name the loader node pointed at, which is a filename, not the weights. To make the record solid, store the hash of the model file that was on disk at render time next to the workflow JSON.
Why does my client's copy of the image have no workflow in it?
Somewhere between your output folder and their inbox the file was re-encoded, most commonly by a JPEG conversion, an editing tool, or an upload pipeline. The image survives that, the metadata does not. Deliver the JSON export alongside the final when the record matters.
Does any of this work for video rendered out of ComfyUI?
The documentation notes that a separate JSON workflow file becomes necessary for media types that lack metadata support, and video output is where that bites in practice. For video deliveries, treat the exported JSON plus your model and input records as the whole story.
What do I need beyond the workflow JSON for a defensible client record?
The model and LoRA files or their hashes, the custom node packs and versions, the input images and masks, the ComfyUI version, and the approval, meaning which render the client accepted and when. The graph covers the computation, and this list covers everything the graph cannot say.