Load Image From URL (Soze)

No download step, no manual save-into-input-folder - Load Image From URL takes an HTTP(S) URL and hands you back a loaded IMAGE, full stop. It's the node you want when your reference image, style target, or ControlNet source lives on the web (a CDN, a bucket, a page you're scraping) rather than already sitting on the machine ComfyUI runs on.

How it works

Give it a URL, it fetches the image over the network and decodes it into ComfyUI's standard IMAGE tensor, same as if you'd downloaded and loaded it manually. It also derives a filename from the URL so you have something to label outputs with, and reports a status so you know whether the fetch actually succeeded.

The inputs and outputs that matter

• url - required, a plain string. Needs to point directly at an image file (or a URL that serves one) - a link to an HTML page that merely contains an image won't work, since there's no scraping logic here, just an HTTP fetch.
• Output: IMAGE - the fetched, decoded image.
• Output: Image_Filename, Image_Filename_No_Ext - a filename derived from the URL, in two forms. Handy for labeling saved outputs so you can trace them back to their source.
• Output: status - reports whether the fetch succeeded. Wire this into a text display, especially in an automated pipeline, so a failed fetch doesn't fail silently three nodes downstream.

How to install it

Via ComfyUI Manager (search "Quality of Life Nodes for ComfyUI" or "Soze") or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/SozeInc/ComfyUI_Soze.git
pip install -r ComfyUI_Soze/requirements.txt

Restart ComfyUI. No API key needed for this one - it's a plain HTTP fetch, distinct from the pack's actual API-integration nodes (ComfyDeploy, FAL, ElevenLabs) that do need credentials.

Common issues & troubleshooting

The fetch fails on a hosted ComfyUI instance. If you're running on a managed or cloud GPU platform, outbound network access isn't always unrestricted - check status first, since a network-policy block will usually surface there rather than as a generic crash.

URL points at a page, not an image file. This node fetches whatever bytes the URL returns and tries to decode them as an image - if the URL is a webpage that merely displays an image (rather than a direct link ending in .png/.jpg/etc., or at least serving image content-type), the fetch will succeed but decoding will fail. Right-click the image on the source page and copy the actual image address, not the page URL.

Some hosts block hotlinking. A URL that opens fine in your browser can still 403 when fetched by a script - some sites check the request's referrer header and refuse direct fetches from outside a browser session. If a specific URL consistently fails while others work, that's the likely cause, and there's no workaround from inside this node beyond sourcing the image from somewhere that allows direct fetches.