🐟Batch Image Compressor

This is the sibling to Image Compressor, and the key difference is the one thing that trips people up: it doesn't take an IMAGE input at all. There's no wire coming from a VAE Decode. Instead you give it a folder path, and it walks that folder - recursively, subfolders included - compressing every PNG, JPEG, and WEBP it finds. It's built for a different job than the single-image node: not "compress what I just generated," but "I've got a pile of images already on disk and I want them all smaller."

What it's for

If you've got a folder full of renders from past sessions, a dataset you're about to upload somewhere, or a batch export from another tool, this saves you from writing a script to shrink them one by one. It's a one-shot filesystem operation dressed up as a ComfyUI node - run the graph once, it processes the whole directory, and you're done. Because it works from disk rather than from the graph, it's also the one to reach for when the images were never part of a ComfyUI generation in the first place.

How it works

Same compression engine as the single-image node - same format choices, same lossy/lossless behavior - just pointed at a directory instead of a tensor. It scans input_path recursively, auto-detects PNG/JPEG/WEBP by file, and re-encodes each one per your format and quality settings. Because there's no images input, this node has to write files to do anything useful - there's no "just convert in memory" option the way the single-image node's images output gives you. What comes back to your graph is a summary, not the pictures themselves.

The inputs and outputs that matter

• input_path - the folder to process. This is the field that makes the node do anything at all; point it at wherever your source images live, and it'll recurse into subfolders automatically.
• format, quality, compression_level, resize_factor - identical meaning and defaults to the single-image node: quality (1–100, default 85) drives WEBP/JPEG, compression_level (0–9, default 6) drives PNG, resize_factor (0.1–1.0, default 1.0) scales pixel dimensions before encoding either way.
• save_image (default on), output_prefix (default compressed_), output_path - same rules as the single-image node: blank path lands in output/compressed, relative paths are relative to ComfyUI's output folder, absolute paths are used exactly as given.

There's just one output, compression_info - a string summarizing the run: how many files, original vs. compressed size, the ratio, and where things were saved. There's no images output here, which makes sense once you remember the input wasn't a graph tensor either; this node talks to the filesystem on both ends.

Installing it

Comes with the same pack as Image Compressor, so if you've already installed one you have both. Via ComfyUI Manager: search ComfyUI-Image-Compressor, install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/liuqianhonga/ComfyUI-Image-Compressor

Restart ComfyUI, then look for image → Batch Image Compressor. No models, no heavy dependencies - it's a thin wrapper around standard image encoding.

Common issues & troubleshooting

Nothing happens, or it errors immediately. Usually input_path points at a folder ComfyUI's process can't actually see - this runs on the machine (or container) executing the workflow, not your local desktop, so a path that exists on your laptop but not on the ComfyUI host will fail. Double-check the path is valid from ComfyUI's point of view before assuming the node is broken.

You expected it to hand images back into the graph and it didn't. By design, not a bug - this node's whole point is bulk filesystem processing, and streaming hundreds of full-size images back into a live graph would defeat the purpose. Need the compressed result in the graph? That's the single-image Image Compressor's job; use this one for archival and cleanup instead.

You compressed a folder of ComfyUI generations and can no longer drag them back in to recover the workflow. Matters more here because you're processing in bulk: ComfyUI embeds the full workflow JSON into a PNG's metadata so you can drag it back in later, a real habit in the community for sharing pipelines. Re-encoding - especially to JPEG or WEBP - can drop that metadata. If any images you're about to bulk-compress are ones you might want the workflow back from, keep an uncompressed copy first.

Only some files in the folder got processed. It auto-detects PNG/JPEG/WEBP by file type and skips anything else, so other file types sitting in the same folder (thumbnails, .json sidecars, non-image files) are silently left alone rather than erroring the whole run.