Image To Base64

The default way ComfyUI hands you an image is a file: SaveImage writes a PNG to disk, and the API response points you at it. That's fine when a human's browsing a gallery. It's the wrong shape when you're calling ComfyUI as a backend service and want the actual image bytes back in the response itself, not a path you then have to fetch separately. ImageToBase64 does exactly what it says - takes an IMAGE and returns it as a base64-encoded string, right there in the run's output.

It's the flagship node of comfyui-easyapi-nodes, lldacing's pack built specifically for people running ComfyUI headlessly. Same author made ComfyUI_PuLID_Flux_ll (the node the community nicknamed "PuLID Flux II," even though it's not an official release) - a different kind of tool, but the same instinct: spot a real gap in stock ComfyUI, ship a focused pack for it. This pack's gap is the seam between ComfyUI's UI-first design (files on disk, dropdowns, galleries) and driving it as an API - which is exactly how a serverless host runs your workflow when you're not clicking Queue Prompt yourself. The community around ComfyUI has built an entire ecosystem of tools - API-format-consuming frontends among them - around getting data in and out of it as something other than files a person clicks through, and this pack is one of the more direct answers to that need from inside ComfyUI itself.

How it works

It's marked as an output node, so like SaveImage it registers as a genuine result of the run - but instead of writing a file, it base64-encodes the image tensor and attaches the string to the run's output data under base64Images. Nothing touches disk. The tradeoff, which the pack's own README is upfront about, is size: base64 strings are noticeably longer than the binary they represent, which can make the UI sluggish on large images and eats more request bandwidth than a plain file reference would. If you're building a production pipeline where that matters, the README's own suggestion is to upload to object storage and pass a URL instead - this node is for when you don't have that infrastructure, or the convenience is worth the extra bytes.

The inputs and outputs that matter

• images (IMAGE, required) - the image or batch to encode. That's the entire input surface.
• Output: base64Images (STRING) - the encoded result. This node always tags the type as "image" internally; if you need to also send masks through the same mechanism and distinguish them on the receiving end, that's what the sibling ImageToBase64Advanced node's imageType option is for.

How to install it

Via ComfyUI Manager, searching comfyui-easyapi-nodes. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/lldacing/comfyui-easyapi-nodes.git
cd comfyui-easyapi-nodes
pip install -r requirements.txt

Restart ComfyUI. No model downloads - this is pure encoding, CPU work, no GPU dependency beyond ComfyUI itself.

Common issues & troubleshooting

The UI feels laggy after adding this node. That's the base64-length tradeoff the README flags directly - long strings in the interface and in the history it keeps can bog things down, especially over several runs. The pack adds a "Maximum History Size" setting (Settings → EasyApi) specifically because keeping too many base64-laden runs in memory can eat RAM; lower it if you're hitting slowdowns.

Response payload is huge / slow over the network. Expected, not a bug - base64 inflates size by roughly a third over raw bytes, on top of whatever transport encoding wraps it. For high-volume or large-image use, moving to object storage plus a URL-based load node is the documented way out.

Getting a string instead of what I expected. base64Images is a plain string output, not a file - if a downstream node needs an actual IMAGE type back, you'd decode it with the pack's Base64ToImage node, not feed the base64 string into an image input directly.