🪐 ✂️ Text Split

Text nodes tend to produce one fat string, and then two different consumers want different halves of it. You write cinematic portrait, soft rim light -- teal and orange grade and the subject half needs to go to one text encode while the style half goes to another. Or you paste an old A1111 parameters block and want the positive prompt separated from the Negative prompt: section. Or a filename has a | with a note on the right you'd rather not feed to a save node.

This node is the scissors: one text in, two texts out, split at a delimiter you type.

How it works

There are two modes, chosen by use_regex.

Literal (default). The split happens on the delimiter as ordinary characters. forward splits on the first occurrence, so text1 is everything before it and text2 is everything after. backward splits on the last occurrence, which means text1 can contain earlier copies of the delimiter - the usual tool for "strip the trailing tag" problems.

Regex. Same forward/backward behaviour, but the delimiter is compiled as a pattern, so \s*--\s* catches the delimiter with whatever whitespace surrounds it. Backward mode finds all matches and takes the final one.

In both modes the delimiter itself is consumed - it doesn't show up in text1 or text2. That's usually what you want, and it's also why you end up wanting strip_whitespace on: split on -- and the left half still carries the space that was in front of it.

If the delimiter isn't found at all, you get the entire input on text1 and an empty string on text2. No error, no warning - the node just declines to split.

If you hand it a broken regex, it doesn't kill the run: it logs the error and falls back to a literal split on the raw string. You get output, just not the output you designed.

Inputs and outputs

You set text (multiline) and split_by (default --). Then the three optional switches: split_direction (forward/backward), use_regex, and strip_whitespace. All of them are tucked under advanced, so on a fresh node you're splitting on the first -- and keeping the whitespace.

Outputs are text1 and text2, both strings. text1 into one CLIP text encode, text2 into another, and you've built a two-part prompt out of one box.

Install

ComfyUI Manager → search SaturnNodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/KOFiblto/ComfyUI-SaturnNodes

Restart. No dependencies used from the pack's Pillow/numpy/piexif list, no models, no install script. Category: 🪐 SaturnNodes/Utils. Older workflows referencing the pack's previous branding resolve through a LeafFlowTextSplit alias, so a loaded graph from before the rename still works.

Where people get burned

\n typed as characters doesn't split lines. In literal mode the box contains a backslash and an n, and that's what it searches for. Turn use_regex on and \n becomes a real newline. Same story for \t and \s.

Everything ends up in text1. The delimiter isn't in the string. Common causes: capitalisation (splitting isn't case-sensitive-adjustable here), a smart quote versus a straight one, or the delimiter buried inside a word where you expected it to be separate. If you need "only when it's a standalone token," use regex mode with \b or an explicit whitespace pattern.

Whitespace pollutes the next node. A leading space on text1 changes how a prompt gets tokenised slightly and looks sloppy in saved metadata. Turn on strip_whitespace when the delimiter was glued to one side of the text.

You expected more than two parts. This is a split-in-two node by design. For a list of blocks, the pack's prompt iterator handles splitting by blank lines; for a full parse of an old generation settings block, this gets you the first cut and you chain another one for the rest.