Load Random Booru Image 🎲

Load Random Booru Image 🎲 does exactly what its name promises: you give it a tag query, it pulls a post from Gelbooru, and it hands you a ready-to-use IMAGE + MASK. No API key, no account, no registration. It's the sibling of Load Random Image (which scans a folder you own) and Load Random Prompt (which rolls a text prompt) - all three are the "stop pointing at one thing, let me pick for you" family from the same pack.

Why reach for it? Mostly reference hunting. Wire it into an img2img or inpaint workflow and every Queue Prompt feeds you a different image pulled straight from the internet, perfect for batch-testing how a checkpoint handles varied compositions. And if you're running anime models - the Illustrious/NoobAI line, Pony - there's a nice loop here: this node feeds you the exact style of Danbooru-tagged imagery those models were trained on, and its post_tags output hands you the tag string that describes it. You can even pipe those tags toward a text encoder and condition on a real post's tags.

How it actually works

There is no usable anonymous Gelbooru JSON API - it answers 401 without a key - so the node scrapes the ordinary search page instead. That sounds fragile, but the README's author clearly did the archaeology: it works out that a page holds exactly 42 thumbnails, computes your position's pid offset from that, reads the total count off the paginator, and fetches the individual post page to dig out the original file URL. Hotlinking is blocked on the file CDN, so it sends a Referer header to get past the 302 redirect back to the post page. Downloads land in a disk cache under ComfyUI's temp dir so a preview and the following execution fetch once, and requests to the site are throttled to one every 0.6s so a batch queue can't turn into a flood.

Everything is proxied through ComfyUI's own routes, so your browser never talks to the booru directly - only your ComfyUI server does.

Inputs that matter

• tags - a space-separated Gelbooru query, exactly what you'd type in the site's search box: 1girl blue_eyes rating:general, cat -comic, sort:score. Leave it empty and you get the whole site, newest first.
• random_post (default on) - picks a new random position on every Queue Prompt, server-side.
• increment_on_queue - walks the result list one position at a time, wrapping at the end. Nice for systematically walking through a tag search. The two checkboxes are mutually exclusive, and the server rejects a workflow where both somehow end up enabled.
• index - the 0-based position in the result list, used when neither checkbox is on. The 🎲 button picks a random one right now and drops it into index without executing the graph.

Outputs: IMAGE, MASK, plus post_id, post_tags, post_url, and index. post_id is the permanent handle - positions shift as new uploads land, so treat index as "6th newest match right now," not a stable pointer. If you want a stable walk, add sort:id:asc to your tags.

The thing nobody warns you about: ratings

This is not a SFW node. Gelbooru's "safe images only" switch is a per-account setting, and the node deliberately sends the site's explicit-content opt-in cookie, so every rating is included - that's intended behavior. Filter with tags (rating:general, -rating:explicit) if you want less. Also know that any prompt containing this node makes outbound requests to a third-party board, and the endpoints are unauthenticated like everything in ComfyUI - if your instance is exposed beyond 127.0.0.1, think before you hook this up.

Install & gotchas

Install via ComfyUI Manager (search "comfyui-bart-nodes") or:

cd <ComfyUI>/custom_nodes
git clone https://github.com/bartenevve/comfyui-random-imageload-node comfyui-bart-nodes

Restart and you're done - it adds no dependencies; the HTTP work is standard-library urllib, and torch/Pillow/numpy already ship with ComfyUI.

Real-world traps: video posts (.mp4/.webm) can't be decoded - random mode retries a few positions, but fixed/increment mode raises an error naming the post, so add -video -animated to your tags. Anonymous deep pagination caps at position 20033 no matter how big the tag set is; narrow the query if you need to dig deeper. And the result list isn't stable - that's inherent to "newest first," not a bug.