Prompt Multiline

Two nodes, one behaviour, one flag

Prompt Multiline is Prompt Line with the prompt widget declared as multiline: True. That's the whole difference in the input schema - same required prompt STRING, same optional prompt_in STRING, same single prompt output, same , join, same strip-the-commas-and-whitespace tidying, same refusal to append a trailing comma. Anyone telling you one is "more capable" is looking at the box, not the node.

Which is exactly why the flag matters, because the box is the interface. A single-line widget in ComfyUI scrolls; a textarea wraps and keeps its newlines. Read the source's join function and you'll see newlines survive into the output - it only strips whitespace at the ends of each fragment, not in the middle. Practically that's harmless: whitespace inside a prompt is whitespace, and a line break costs you nothing the encoder cares about. It just means you can lay out a long prompt the way you'd write it, one clause per line, instead of one wall of text you re-read six times looking for a typo.

That's not cosmetic, by the way. The KB's prompt-engineering notes make the point that structure is what actually binds attributes to subjects - a clean, well-separated description works, tag soup with three unrelated concepts bleeding into each other doesn't, and the LLM-encoded models that took over local generation in late 2025 are far less forgiving of mush than CLIP ever was. You can't structure a prompt you can't read. A wrapping box is a small quality-of-life win that shows up in your output.

The one real functional difference

Both nodes disable the frontend's dynamic-prompt expansion on their own text box (dynamicPrompts: False in the source), so neither will expand {red|blue} alternatives or __wildcard__ file references. If you rely on that syntax in a text widget, this pack's text nodes will hand it downstream literally. Use them for prose, not for templating.

What differs in practice

• Reading. Multiline wraps and scrolls vertically; multiline prompts in a textarea are easier to review before a run than a box you have to click into and arrow through.
• Layout. Newlines are preserved, so a line per concept is cheap and self-documenting.
• Prompt sections. If you keep a style block, a subject block and a lighting block, the multiline box lets you see all three at once and reorder them by dragging lines - the same edit in a single-line widget is a cursor-position hunt.
• Screening. Once you start writing inside that box, you can drag its edges to size it. Do that early; a two-line box on a 300-word prompt is miserable and it's a two-second fix.

Everything else - the join, the comma stripping, the order of the fragments, the empty-input behaviour - is identical, so the earlier notes on Prompt Line apply here verbatim.

Inputs and output

• prompt (STRING, required) - the multiline textarea.
• prompt_in (STRING, optional, force-input) - upstream text, placed ahead of the box's contents.
• Output: prompt (STRING).

Wire it into CLIP Text Encode.text. If that text field still renders as a widget, right-click it and pick Convert widget to input - the README points this out and it's the standard step for any text node.

Install

Part of the same pack; no third-party Python dependencies. Search Prompt Warehouse in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/D33MO/ComfyUI-Prompt-Warehouse.git

Restart ComfyUI and reload the browser page. Both prompt nodes appear under the Prompt Warehouse category.

Which one to open

If you write sentences, take this one. If you're chaining tags and want the node compact so the graph stays readable, take Prompt Line. The short version: the difference only shows up in the workflow canvas, but you look at the canvas all day, and staring at a one-line box that hides 80% of your prompt is a small tax you pay on every single run.