AQ_SaveImageWebpReturnBase64
Save a WEBP to disk and hand the base64 straight to your own frontend
- images
Most save nodes in ComfyUI write a file and post a preview. AQ_SaveImageWebpReturnBase64 does that and sends the actual image back to whoever called the workflow as a base64 string - which is the whole point. If you're running ComfyUI from a custom frontend or a script that polls the API for results, this node means you don't have to go hunting in the output/ folder and guess which file was just written. The image arrives in the response, ready to decode.
The README frames the pack's API story as "don't want to poll comfy to see if generation is ready," and this is that idea applied to a single save. It's niche - most people never need it. You want it if you're building your own ComfyUI frontend, an automation pipeline, or a little web app that generates on demand and expects the bytes back.
How it works
Straight from the source: for each image tensor it converts to a PIL image, encodes it to a WEBP in memory, base64-encodes that buffer, then returns it through the UI payload as
{"images": [{"type": "base64Image", "name": "<filename>", "data": "<base64...>", "seed": 0}]}
So the base64 isn't a port you wire other nodes into - it rides along in the result payload, where the API layer (or your custom UI) picks it up. Meanwhile the same bytes get written to disk as a .webp in ComfyUI/output/user_<client_id>/, with a sidecar .txt file holding the prompt text, plus the whole generation's settings embedded as EXIF UserComment metadata: prompt, cfg, steps, scheduler, sampler, and seed.
That last part is the quiet useful bit. The metadata is written into the file itself, so a WEBP saved here is self-describing - you can recover what generated it later without the workflow JSON.
The inputs that matter
The required inputs are images plus a stack of mostly-metadata fields: name (the filename prefix, default "image"), seed, prompt_text, cfg, steps, scheduler, sampler. Here's the thing: cfg, steps, scheduler, and sampler don't change how saving works at all. They're free-form strings and numbers that get embedded into the EXIF so the file remembers its own generation settings. Only two inputs actually do something you'll notice:
- images - the IMAGE tensor(s) to save. Batches get separate files, numbered and suffixed with random letters, so nothing overwrites.
- name - the prefix each file starts with. Leave it unless you're sorting output by purpose.
Everything else, fill in if you want honest metadata; the save works fine with them at defaults.
Installing it
Same story as every node in this pack - install AQnodes, not the node:
cd ComfyUI/custom_nodes
git clone https://github.com/2frames/ComfyUI-AQnodes
then restart ComfyUI, or use ComfyUI Manager and search "AQnodes". (The README's clone URL is an un-updated yourusername template - use the real repo.) This node needs no extra pip packages; it only uses what ComfyUI already has.
Gotchas
- The base64 is a full WEBP per image. A big batch means a big response payload - don't expect this to stay snappy with hundreds of images.
- Files land in
output/user_<client_id>/, not the root output folder. That client-specific subfolder trips people up when they go looking for the file. - If the
IS_DEVenvironment variable is set, the node switches to a different, debug-shaped return. Unless you set that variable, ignore it - but it exists. - There's no output port, so you can't chain this into another node. It's an endpoint node: whatever comes out of it goes to the frontend or the API consumer, not back into the graph.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| name | STRING | image | — |
| seed | INT | 00–18446744073709550000 | — |
| prompt_text | STRING | — | |
| cfg | FLOAT | 0.000–50 | — |
| steps | INT | 0 | — |
| scheduler | STRING | — | |
| sampler | STRING | — |
Outputs (0)
No outputs