😼> Text

A dozen packs ship a plain multiline text box node, and on the surface this is another one of those. The reason to reach for this specific version is the free second output: it hands you a live character count alongside the text itself, no extra node required.

How it works

Type into the multiline field, and the node outputs both the raw string and its length in characters. The text output goes anywhere a STRING is expected - prompt encoders, this pack's own Save Text node, or Text Count if you want a word or line count instead of characters. The char_count output is the part worth building a habit around: wire it into a display node and you've got a live readout while you're editing a prompt or caption, useful for keeping something under a length limit some other node in your graph enforces.

The inputs and outputs that matter

• text (STRING, multiline, default empty) - the input field itself.
• text (STRING) out - the same string, passed through for wiring elsewhere.
• char_count (INT) out - the character count of that string.

How to install it

Via ComfyUI Manager: search "yanc" or "ComfyUI_yanc" and install, then restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ALatentPlace/ComfyUI_yanc

then restart ComfyUI. No extra dependencies or model downloads.

Common issues & troubleshooting

You're using char_count as a token budget and it doesn't line up. It's a character count, not a token count. CLIP and T5 tokenizers don't map 1:1 to characters - punctuation, subwords, and multi-character tokens all throw off a straight character-based estimate. Treat this as a rough sanity check, not an actual token gauge; if you need real token counts, you need a tokenizer-aware node, which this isn't.

You want to count words or lines instead of characters. This node only gives you char_count. This pack's separate Text Count node covers chars, words, and lines from an enum, and works on any STRING input, not just this node's own output - use that one if characters aren't what you're after.

Multiline formatting looks different once it reaches a downstream node. Some prompt encoders and text nodes normalize whitespace or newlines differently. If the text output looks right in this node's own widget but behaves oddly further down the graph, that's usually the receiving node's handling of line breaks, not this one mangling anything.