PNG Metadata vs. Workflow JSON: A Persistence Guide

ComfyUI saves your workflow in at least three different ways—and none of them capture everything. This guide maps exactly what each format preserves, what it silently drops, and where the gaps create real reproducibility problems at scale.

Why This Matters More Than You Think

ComfyUI’s node-based architecture gives creators granular control over every step of the generation pipeline. But that granularity creates a metadata problem: the information needed to fully reproduce an image is scattered across node configurations, model references, and runtime parameters that no single export format captures completely.

For individual creators, a missing scheduler config is an inconvenience. For teams producing thousands of assets weekly—operating in an environment where 34 million AI images are generated daily—incomplete metadata means lost provenance, broken reproducibility, and governance gaps that compound over time.

I think about this in two parts: what the format structurally captures, and what it practically preserves when you try to reload a workflow six months later on a different machine.

The Three Formats, Defined

ComfyUI produces three distinct persistence formats. Each serves a different purpose and encodes a different slice of your workflow state.

1. Embedded PNG Metadata

When ComfyUI’s default SaveImage node writes a PNG file, it embeds two separate data chunks into the file’s tEXt metadata fields:

• prompt: The API-format JSON (the execution graph with resolved values)
• workflow: The full UI-format JSON (node positions, widget states, connections)

This means a standard ComfyUI PNG technically contains both of the other formats embedded inside it. The PNG is the most complete single-file artifact ComfyUI produces by default.

2. Exported Workflow JSON (UI Format)

This is what you get when you click “Save” or use Ctrl+S in the ComfyUI interface. It captures:

• Every node’s type, position, and size on the canvas
• Widget values (prompts, seeds, step counts, CFG scale)
• Connection graph between nodes (links array)
• Group definitions and layout metadata

This format is designed to reload the editor state. It’s a UI document, not an execution record.

3. API-Format JSON (Execution Format)

Exported via “Save (API Format)” or captured by intercepting the /prompt endpoint. It captures:

• The flattened execution graph with resolved input values
• Direct node-to-node connections by ID
• Class types for each node

This format is designed to re-execute the workflow programmatically. It strips all visual layout data and anything the execution engine doesn’t need.

Field-by-Field Comparison: What Survives Where

Here’s where the differences become concrete. This table maps critical workflow parameters to their persistence status across formats.

The pattern is clear: all three formats handle parameter values well. They all fail at environmental context—the version of ComfyUI, the specific model file behind a name, the custom node versions that determined runtime behavior.

The Five Critical Gaps

After mapping this field by field, five gaps stand out as the most consequential for reproducibility and governance.

Gap 1: Model Hashes Are Absent Everywhere

ComfyUI stores model_name: "v1-5-pruned-emaonly.safetensors" but never the file’s hash. If someone replaces that file with a different model using the same filename—common when teams iterate on fine-tunes—every workflow referencing that name now points at a different model with no way to detect the change. This is the single largest reproducibility risk in the ComfyUI ecosystem.

Gap 2: Custom Node Versions Are Invisible

A workflow referencing CR Apply LoRA Stack from ComfyUI-Custom-Scripts v1.2 may behave differently than v1.8. No format records which version was installed at generation time. As the average team uses 3+ AI tools—often with overlapping custom extensions—this creates silent behavioral drift.

Gap 3: The PNG Is Only Complete if You Use the Default Save Node

Third-party save nodes (like those for WebP, JPEG, or batch-output nodes) typically don’t embed workflow metadata. Video output nodes don’t embed it. Any format other than PNG from the default SaveImage node likely produces a bare file with zero provenance.

Gap 4: Negative Prompts Survive but Get Buried

All three formats do preserve negative prompt text—a common misconception is that they don’t. The confusion arises because the negative prompt lives in a separate CLIPTextEncode node, not adjacent to the positive prompt. Automated extraction tools that look for a single “prompt” field often miss it. The data is there; the discoverability is poor.

Gap 5: API JSON Loses the Ability to Visually Audit

The API format strips node positions, group labels, and canvas layout. For complex workflows with 50+ nodes, this means you can re-execute the workflow but can’t visually inspect its logic. Teams reviewing workflows for compliance or quality checks lose the ability to audit without first loading the UI-format JSON back into ComfyUI.

Practical Recommendations by Use Case

Solo Creator: Personal Reproducibility

Save the PNG. It contains both the workflow and API JSON embedded. Back up your models folder separately with a hash manifest (tools like sha256sum or ComfyUI Manager’s model list can generate these). This gives you 90% coverage.

Team: Shared Asset Libraries

PNGs alone won’t scale. You need:

• Workflow JSON files version-controlled in Git alongside the project
• A model hash registry mapping filenames to SHA256 hashes at the time of generation
• A custom node lockfile (similar to requirements.txt) recording installed extensions and versions

Pipeline Builders: ComfyUI API

Capture API JSON at execution time from the /prompt endpoint and supplement it with environmental metadata your pipeline can inject: model hashes, node package versions, ComfyUI commit hash, and timestamps. The API JSON is your execution record; the supplemental metadata is your provenance record.

Regulatory Compliance: EU AI Act and SB 942

No default ComfyUI format is sufficient. The EU AI Act requires demonstrable provenance for AI-generated content, with penalties up to 3% of global revenue. California’s SB 942 imposes fines of $5,000/day for non-compliant AI content disclosure. Both require information—model identity, generation parameters, timestamps—that must be assembled from multiple sources and stored in a durable, tamper-evident format beyond what ComfyUI natively provides.

Where Infrastructure Fills the Gap

The pattern across all five gaps is the same: ComfyUI captures what happened inside the graph but not the environment the graph ran in. Parameter values are preserved. Context is not.

This is a metadata infrastructure problem, not a ComfyUI design flaw. ComfyUI is an execution engine optimized for flexibility and speed. Provenance, lineage tracking, and long-term findability are concerns that belong in a dedicated layer—one that captures environmental context at generation time, links assets to the specific model files and tool versions that produced them, and makes that information findable and governable after creation.

Without that layer, creative teams end up spending portions of their time on what amounts to digital archaeology—reverse-engineering which model, which LoRA version, which node configuration produced a specific result. Research suggests this kind of search-and-reconstruct work consumes up to 25% of creative teams’ time.

The memory of how an asset was made shouldn’t depend on which save node you happened to use.