Single image to base64 keep metadata

In this ecosystem, a PNG is never just pixels - it's a project file with the whole workflow baked into it as text chunks. Single image to base64 keep metadata is the version of the base64 node that doesn't throw that away. It does exactly what Single image to base64 does - first image in, data:image/png;base64,.... string out - but before encoding, it writes the current workflow and prompt data into the PNG as text chunks. So the image you embed in an HTML page or hand to an API still carries its provenance, and if anyone drags the decoded PNG back onto a ComfyUI canvas, the graph reconstructs.

How it works

The difference from the plain version is one deliberate step. The node grabs extra_pnginfo - the workflow and prompt JSON that ComfyUI's frontend passes along with a run - and adds it to a PngInfo object, which PIL writes into the PNG as text chunks before the base64 encoding happens. That's the same mechanism core SaveImage uses, which is why the encoded image has the metadata property at all. One guard rail: if ComfyUI is running with metadata disabled (--disable-metadata in your launch args, or the equivalent setting), the node honors that and skips writing the chunks.

The inputs and output

Identical to the plain version:

• images - an IMAGE tensor; only the first image of the batch gets encoded.
• Output: base64Image, a STRING, ready for an <img src> attribute or whatever string consumer you have.

Install

Search ComfyUI_html in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/filipemeneses/ComfyUI_html

Then restart. No models, no dependencies.

The honest caveats

"Keep metadata" is doing a specific job, and it's easy to over-read the name. It keeps the current workflow's metadata - whatever graph is running right now - not arbitrary metadata from an original file. The input is a decoded tensor, so the source file's chunks never survive the round trip anyway. And it only works when the workflow actually provides extra_pnginfo: run headless or via API and there's often nothing to write, which silently makes this node behave like the plain one. Add the usual base64 caveats - a 1024² image is 2–3 MB of text, and embedding it in an email makes the email that much heavier - and you have the full picture. It's the right tool when the embedded image might someday need to explain itself, and it costs you nothing except a little extra weight in the string.