Equal to

Equal to does exactly what you'd hope: two numbers in, and a true out only when they're the same. It's the comparison at the heart of the pack's own format-selection demo workflow, where it checks whether an image's width matches a known value before deciding which prompt to use. In a world where ComfyUI's boolean toolbox was basically empty, a clean == is a genuinely useful thing to have.

It comes from marco-zanella's ComfyUI-BooleanExpression pack, a dependency-free logic collection. This is the arithmetic sibling of the string-side "Equal to" node, and it's the one you want when you're comparing numbers, not text.

The inputs

Two required inputs, both INT or FLOAT:

• first - the first number (default 0)
• second - the second number (default 0)

Output is result, a BOOLEAN: first == second. Mechanism is a Python equality check - nothing more, nothing less.

Where it earns its keep: checking whether a value is exactly a sentinel or a configured constant. The README's conditional-format-prompt workflow uses it to detect a specific aspect ratio and route to the matching prompt. That "is this exactly X" pattern is the node's niche - you're testing identity against a known value, not a threshold.

Installing it

Zero dependencies, zero models - the pack's requirements.txt is empty and it's pure Python. ComfyUI Manager, search ComfyUI-BooleanExpression, or:

cd ComfyUI/custom_nodes
git clone https://github.com/marco-zanella/ComfyUI-BooleanExpression.git

Restart ComfyUI and find it under Boolean Expressions → Arithmetic Comparisons.

The trap: floating point

Here's the honest warning. Equality is the comparison most likely to silently bite you, because the numbers you type and the numbers Python stores aren't always the same. 0.1 + 0.2 is not exactly 0.3 in floating point, so a check like "is the computed value equal to 0.3" can return false when you're staring at two values that look identical. This isn't a bug in the node - it's how IEEE floats work - but it's why:

• For integer values (steps, batch size, seeds), Equal to is rock solid.
• For computed floats (scaled resolutions, averaged values, anything that came out of a math node), exact equality is a gamble. If your threshold is meant to be "roughly this," reach for Less than / Greater than (or the inclusive variants) to build a range instead, or compare against a value you can snap to an integer first.

People trip on this constantly in the community, and it's the exact spot where Equal to stops being obvious. Keep it for discrete values and you're fine.

Other gotchas

• Both branches downstream still compute. A comparison selects a value; the unselected chain upstream runs anyway. Negligible for numbers.
• Re-check defaults after duplicating - the two inputs default to 0, so a fresh copy reads "0 == 0 → true" until you wire real values in. That's a "wait, why is this always on" moment waiting to happen.

For string equality, grab the string-side "Equal to" from the same pack - same idea, but case-insensitive by default, which is its own little trap to read about. Here, for numbers, Equal to is the clear, obvious choice - just don't hand it a float that was ever computed.