Any -> Base64

This node takes any wire in your graph - a latent, a conditioning, an image tensor - and hands you back a plain text string. That's the whole job, and it sounds pointless until you've hit one of the problems the pack exists to solve: moving ComfyUI data between machines, caching expensive intermediate results, and shuttling data between two workflows that have no business sharing a canvas.

The scenario the README pushes, and it's a real one: CLIP text encoding is cheap and repeatable, and your negative prompt's conditioning is the same bytes every single run. The U-Net denoise is not cheap. So instead of re-running the whole graph, you run the light parts (text encode, VAE, building a latent) once on a weak box or CPU, serialize the conditioning or latent to a Base64 string, and send that string over an HTTP API to a machine with actual GPU. The remote box only runs the KSampler. Base64 is the least common denominator every transport can carry - a JSON field, a database column, a clipboard, an email. The name is a lie in one way: it's not encoding to any base64, it's Python's torch.save wrapped in base64. No API, no key, no server.

How it works

Mechanically it's two steps. The node calls torch.save on whatever arrives, writing the object into an in-memory buffer, then base64-encodes those bytes into a UTF-8 string. Serializing is safe - nothing gets executed on this side; the danger lives in the decode nodes, not here.

One accuracy note that matters if you read the README: it claims tensors are moved to CPU before saving, but the shipped code (v1.0.0) doesn't actually do that - it just torch.saves in place. The "smart device handling" you get for real happens on the other end, where the Base64To* nodes force everything back to CPU with map_location. Net effect is the same, and it's a good one: a latent serialized on your 4090 will load fine on someone's MPS Mac or CPU box, no device-mismatch crash.

Inputs and output

There's exactly one input, any, and it's a wildcard * socket - the same escape hatch that switch nodes use. It accepts a LATENT, CONDITIONING, IMAGE, MASK, or pretty much any PyTorch object you throw at it. The single output is b64_string, a plain STRING. That's the whole interface, no knobs.

The node is marked as an output node in source, the same class as Preview/Save Image. That means it always runs and never gets skipped by ComfyUI's cache - which is what you want when you're exporting fresh data. The flip side: if this is your graph's terminal node, everything upstream executes every run. Fine for an export, mildly annoying if you leave it parked mid-graph.

Installation

Install once for the whole pack via ComfyUI Manager (search ComfyUI_Base64_IO), or:

cd ComfyUI/custom_nodes/
git clone https://github.com/lenML/ComfyUI_Base64_IO.git

Then restart ComfyUI. The pack is from lenML, a prolific solo dev (they also maintain Speech-AI-Forge); this is a small MIT utility with zero dependencies - requirements.txt is empty and it's stdlib plus torch, which ComfyUI already ships. No model downloads.

Gotchas

• Size. Base64 inflates raw bytes by about a third. A 512×512 latent comes out around 90 KB of text; a batch of four at 1024×1024 is a third of a megabyte. Totally fine for a database or API call, silly to hand-paste.
• Grabbing it via the API is easy because the node returns {"ui": {"text": [b64_str]}, "result": (b64_str,)} - the string shows up in the UI payload so an external client can fetch it straight out. Paste it into a text widget on the Base64To* side and it round-trips.
• The security warning is on the other side - Base64To* uses torch.load(weights_only=False), so only decode strings you generated yourself. See the decoder articles for why that matters.

If you just want to move a latent between machines, pair this with Base64ToLatent. If you're caching a prompt's conditioning so you never re-run CLIP, the sibling Base64ToConditioning is the more natural mate. This node is the encoder half of both.