Save Base64 (Websocket)

The node that deliberately does nothing visible

If you drop Save Base64 (Websocket) into a workflow and hit Run, nothing happens on screen. No image appears. No file lands in your output folder. The node looks broken - and that's the entire point. Its job is to take a base64 string and push it out of ComfyUI over the websocket, straight to whatever client is listening. It's the output half of the base64 round trip, and it's the node you reach for when your pipeline's result needs to reach your code, not the filesystem.

What it's for

ComfyUI talks to the outside world through its API: you POST a workflow to /prompt, and results stream back over a websocket. That's how the default browser frontend works, and it's how any headless server, web app, or remote client talks to ComfyUI too. The problem: most of what a workflow produces - images, audio, JSON - lives on the server's disk. If you're running ComfyUI as a stateless API backend (think multi-user web apps, cloud workers, mobile clients), writing files to a shared filesystem is a headache you don't want.

This node sidesteps it. Feed it any base64 string - from ImageToBase64, FirstFrameToBase64, LastFrameToBase64, or an API response - and it publishes the string over the websocket in the executed message for the node, where your client code reads it directly. Nothing touches disk. That's why the README calls the whole pack "highly useful for integrating with the ComfyUI API implementation."

How it works

The mechanism is almost insultingly small. The node is flagged as an output node (OUTPUT_NODE = True), takes your base64 string, and returns:

{"ui": {"base64": [base64]}}

ComfyUI picks up that ui dict and sends it over the websocket as part of the node's execution result. It's the same channel the browser frontend uses to stream preview images back to the UI - you're just riding it with a plain string instead of pixels. A client listening on /ws sees the value arrive in the executed message under data.node's base64 field. No files, no temp dirs, no cleanup.

Input and output

There's a single required input: base64 (STRING). And no outputs - check the node and you'll see no output sockets at all, which is normal and not a bug. There's nothing to wire onward from; the data leaves over the wire, not through the graph. (The node does have one side effect: because it's an output node, ComfyUI always runs it even if nothing downstream "needs" it, which is what makes it reliable as a sink for results.)

Installing it

Search ComfyUI-Base64-Nodes in ComfyUI Manager, install, restart. Manual install:

cd ComfyUI/custom_nodes
git clone https://github.com/dewittethomas/ComfyUI-Base64-Nodes
pip install -r requirements.txt

No models, no heavy dependencies - the pack's only requirement is imageio-ffmpeg, and this particular node doesn't even use ffmpeg. Find Save Base64 (Websocket) under the Base64-Nodes category.

Where people get burned

• You expected a file. If you just want to save an image or audio to disk, this is the wrong node - use a regular saver. This one returns data to a client, not to disk.
• Nothing happens in the browser. The default UI isn't really listening for this node's output, so it looks inert. The data shows up only if you're running your own websocket client against the API. That's a feature, but it's a confusing one if you're new.
• You need the client side too. This node is half a conversation. The other half is your Python/JS code reading the websocket executed message. If you're not writing that code, the node is pointless.
• Pair it with the decoders. To close the loop, send base64 into ComfyUI with Base64ToImage or Base64ToAudio, and pull results out with this node. Round trips, no disk, no drama.

It's a niche utility with near-zero Reddit footprint, MIT-licensed, no network calls - about as safe a custom node as exists. For anyone building on the ComfyUI API, it's the missing glue between the graph and your application.