Boolean Input (FormInput)

This node is a single on/off switch: you flip it, it passes a True or False down the wire. But the switch part is the whole story, because it's one of the few boolean nodes in ComfyUI that renders like something a human being would actually click.

How it works. The node declares one required input, boolean, a BOOLEAN with a default of True. The source also sets label_on: "True" and label_off: "False" - those keys are what make the frontend draw it as a toggle switch with readable labels instead of a raw true/false widget. process_boolean just returns the value untouched, under the output name boolean_output. Pure pass-through, same DNA as the rest of the FormInput pack.

Why you'd reach for it. The pitch for this pack is "forms." If you're building a workflow you'll share - or that runs on a machine owned by someone less invested in the graph than you - a labeled switch beats a checkbox buried in a node's properties. "Hires fix on / off," "use the detailer," "skip the upscale pass": these are exactly the kind of thing a switch communicates instantly. The other angle is genuinely useful: a visible boolean you can wire into any node that declares a BOOLEAN port, which a bunch of utility packs (rgthree-style graph tools, WAS, Impact) use for their conditional inputs.

One honest caveat about reach: not every boolean in ComfyUI is a port. Lots of settings - KSampler widgets, strength sliders - are widget inputs, not BOOLEAN-typed ports, and this node's output won't plug into an INT or FLOAT socket no matter how hard you pull. For those, right-click the target widget and "Convert widget to input," or just use the widget. And before you ask: yes, the stock Primitive can hold a boolean too. If you're building only for yourself, Primitive covers most of this. The switch earns its keep when the workflow is meant to be read by another person.

Install. Same pack as the other two - search "FormInput" in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/monkeyWie/ComfyUI-FormInput

Restart, and it's under the "FormInput" category. No requirements.txt, no models, nothing to conflict with. It's a single-commit project from May 2025, so the maintenance story is "it's done and it works," not "actively developed."

The traps. The output is a hard BOOLEAN - it will not drive a strength slider or any numeric input. And the toggle state persists in the saved workflow: leave it on, share the file, and it ships on. Since the default is True, that's an easy way to hand someone a workflow where the "off" behavior they wanted is silently flipped on. Flip it, check it, then save.