IMAGE WebSocket Web Viewer (Legacy) @ vrch.ai

"(Legacy)" in a node name usually means "old and complicated," and in this case the reputation is earned - but not because it's broken. The IMAGE WebSocket Web Viewer (Legacy) is the original all-in-one WebSocket viewer: the whole behavior stack - blend modes, loop control, background color, save settings - crammed onto a single display node. The newer approach splits that into the simple viewer plus a separate settings node. This is the version that old workflows load, and the reason you'll most likely meet it is that you opened a shared graph built before the split.

What it is

Mechanically it does what every WebSocket viewer does: takes images, pushes them over the socket to server (default 172.17.0.2:8001, the usual Docker dev leftover - set it to your actual server address) on a channel (1–8), and pops a browser window. format picks PNG or JPEG (JPEG default). number_of_images, image_display_duration, and fade_anim_duration control the rotation and crossfade pacing.

The legacy giveaway is the long tail of behavior knobs sitting right on the node: blend_mode with 17 CSS blend options for layering images, loop_playback (default on) and update_on_end for loop behavior, background_colour_hex (default #222222) for the viewer background, server_messages for injecting a message string, and save_settings to persist your settings across runs. In the new architecture those all live on the IMAGE WebSocket Settings node instead. Same controls, different home.

The window and debugging knobs match the family: window_width/window_height (defaults 1280×960), show_url, dev_mode, debug, plus the extra_params and url escape hatches. Outputs are IMAGES (passthrough) and URL (the viewer address as a string).

So which do you use? If you're loading an existing workflow that uses this node, leave it - it works fine and there's no reason to migrate a working graph. If you're building new, prefer the simple viewer plus the settings node; that's the maintained path, and keeping behavior separate from display makes a workflow far easier to read when you come back to it next week. That split is the same reason this pack keeps both versions around: backward compatibility without forcing new work onto the old shape.

How to install

Install is the pack-standard path:

cd ComfyUI/custom_nodes
git clone https://github.com/VrchStudio/comfyui-web-viewer
cd comfyui-web-viewer
pip install -r requirements.txt

restart ComfyUI. Manager users search "ComfyUI Web Viewer". Windows portable: python_embeded\python.exe -m pip install -r ComfyUI\custom_nodes\comfyui-web-viewer\requirements.txt. No models involved.

Common issues

Troubleshooting mirrors the WebSocket family: a silent empty window means the server address isn't resolving to a running server, and if you're mixing it into a workflow alongside newer WebSocket nodes, keep channel numbers straight. The one true "legacy" behavior to watch for: because everything is inline on this node, it's easy to lose a specific setting inside a wall of fields - which is precisely the problem the new split was designed to solve.