Or

And is the strict one - everything must pass. Or is the forgiving one: true if any single value is truthy, and only false when everything is falsy. If your workflow should take the special path when any of several conditions are met - this model OR that model OR the strength slider is past a threshold - Or is the node that collapses all of them into a single wire.

It's the sibling of And, which is why the two are usually discussed together. And gates a branch on everything being true; Or gates it on anything being true. Between them you can express most conditions a graph actually needs, and you'll almost always use one to feed the other.

How it works

Or runs Python's any() over its inputs and returns a BOOLEAN. Like And, the values input is autogrow: add as many value connections as you want, and the node grows to fit. Two conditions, five conditions, ten - same node, same output.

And like And, it follows Python's truthiness rules, so the inputs don't have to be booleans at all. A non-empty string counts as true. 0, an empty string, an empty list, and None all count as false. One practical trick this unlocks: if you wire several optional inputs into Or, it returns false when all of them are missing or empty, and true when any of them actually holds a value - a "did anything arrive?" check in one node.

The inputs and outputs that matter

• values (any type, autogrow) - add as many as you need. The output is true if any of them is truthy.
• BOOLEAN output - true if any value is truthy, false only if all are falsy. Wire it into an If/Else Switch's switch input, or into an And node to build "all of these, but any one of those" logic.

How you get it

Ships with ComfyUI core in the utilities/logic category, added in early 2026. No install - just make sure your ComfyUI is recent enough to have it.

Common issues

"It's true and I wanted false." Something in the pile is truthy that you didn't expect. The classic: a string "0" or "false" is a non-empty string, and Python treats non-empty strings as true. If you're wiring in values that came out of text widgets or comparisons, look at what's actually on each input before you blame the node.

"Why is it false when I know one input had a value?" Then one input didn't hold what you think it did - empty string, zero, or None are all falsy. Or only trips when every single input is falsy, and the debug move is to check each value with a display node. There's no ambiguity in the logic; there's only ambiguity in what's arriving.