Nodes/ComfyUI_NetDist_Plus/Latent to Base64
ComfyUI Node

Latent to Base64

The least battle-tested node in the pack, and the author says so

By nux1111·Created 2 years ago·Updated 2 years ago· 39
Latent to Base64
  • samples
  • base64_latent

This node does for LATENT tensors exactly what ConditioningToBase64-Nux does for conditioning: flattens it into a plain base64 string that can actually leave the process it was created in. Two separate ComfyUI instances have no shared memory, so a LATENT output on one machine is worthless to a KSampler or VAE Decode on another unless something turns it into bytes that can travel - over the network, or riding embedded inside a saved image.

What it's for, and the honest caveat up front

Before anything else: the pack's own README lists this under its "Issues" section in the author's own words - "Remote Latents: I didn't get a chance to test it." That's not a minor footnote. It means the latent round trip in this pack shipped without the author fully verifying it end to end, unlike the conditioning path, which is the one he actually built a demonstrated workflow around. If you're reaching for this node, know you're in the least-trodden corner of the pack.

That said, the intent is straightforward: wire the samples output of a KSampler (or wherever your latent comes from) into this node, on whichever instance produced it, and get back a string you can move to another machine - either by wiring it directly through this pack's network nodes, or by feeding it into SaveImageWithBase64-Nux's optional latent socket so it's embedded in a saved PNG for later retrieval.

Inputs and outputs

One input: samples, a standard LATENT socket.

One output: base64_latent, a plain string. On the receiving end, LoadLatentFromBase64-Nux turns it back into a real LATENT.

Installing it

ComfyUI Manager: search ComfyUI_NetDist_Plus. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/nux1111/ComfyUI_NetDist_Plus
pip install requests

Restart ComfyUI. No model downloads for this node.

Where people get burned

Beyond the "author never fully tested this" warning above, the practical trap is a model mismatch. A latent tensor's shape and scale are tied to whatever VAE and model architecture produced it - SD1.5, SDXL, and Flux latents aren't interchangeable, and this node has no way of checking that for you. It serializes whatever tensor you hand it; if the receiving instance tries to decode it with an incompatible VAE, you'll get garbage or an outright crash, and the failure will show up downstream in LoadLatentFromBase64-Nux or VAE Decode, not here.

Given the untested status, the practical advice is to treat this as an experiment rather than something to build a production pipeline around. If you just need to move a finished image between two GPUs, the pack's conditioning path - and the plain image fetch that FetchRemoteWithExtras-Nux already does - is the far more proven route. Reach for latent serialization specifically when you need the actual noise/denoise state to survive the trip, and go in expecting to do some of your own debugging.

Categoryremote/latent

Inputs (1)

NameTypeDefaultDescription
samplesLATENT

Outputs (1)

NameTypeDescription
base64_latentSTRING