BS Textchop (Smart)
Chop any string by markers — BS Textchop (Smart) without a line of regex
- extracted_text_1
- extracted_text_2
- extracted_text_3
- extracted_text_4
- extracted_text_5
- extracted_text_6
- extracted_text_7
- extracted_text_8
- extracted_text_9
- extracted_text_10
The one-paragraph pitch
Every once in a while your workflow hands you a wall of text - a long caption, a shared prompt, a blob of LLM output, a metadata block - and you need one slice of it. Maybe the subject line. Maybe the style tags. Maybe everything after some marker. That's the whole job of BS Textchop (Smart): it pulls a segment out of any string using start/end markers, with zero regex, zero API calls, zero models, and - unusually for this ecosystem - zero dependencies beyond Python itself.
It's a one-trick node from Burgstall-labs, the hobby account behind those gloriously silly LTX-2.3 IC-LoRAs (GooglyEyes, the head-shrinking TSANTSALIZE). If you've grabbed any of those you'll recognize the vibe: small, practical, a little self-deprecating, and it ships a real ComfyUI workflow. The "Smart" in the name isn't AI marketing - it means the extraction adapts to whether you give it a start marker, an end marker, or both.
How the "smart" extraction works
The whole node is one small Python file using str.find(). It's literal substring matching - not regex, not an LLM, no vocabulary, no case folding. Each of the 10 marker pairs behaves in one of three ways:
- Both markers filled in: text between the first occurrence of the start marker and the first subsequent occurrence of the end marker.
- Only start marker: everything from right after the start marker to the end of the input.
- Only end marker: everything from the start of the input up to the first end marker.
First occurrence only, case-sensitive, character-for-character. [start] will not match [START], and a space in a marker is part of the marker. Pairs with both fields empty are simply ignored, and a marker that can't be found yields an empty string rather than an error - which is the genuinely useful bit. Wire in several pairs, feed it a stream of texts where markers sometimes don't exist, and the missing outputs just come back "" instead of crashing the run.
Inputs and outputs
The inputs that matter are few, which is the point:
- text (required, multiline) - the string you're slicing.
- start_marker_1..10 / end_marker_1..10 - the ten literal marker pairs.
The outputs are extracted_text_1 through extracted_text_10, one per pair, empty when a pair is inactive or a marker isn't found. They're plain STRINGs, so wire them into anything that takes text: a CLIP Text Encode, a prompt scheduler, a concatenation node, or a Show-Text-style debug node to eyeball what you actually extracted. A classic setup: a text file or LLM output feeds the prompt, and this node slices out only the subject line or only the style block so the rest of the pipeline sees clean input.
Install
Same as any custom node - ComfyUI Manager: search "ComfyUI-BS-Textchop" and install, or:
cd ComfyUI/custom_nodes
git clone https://github.com/Burgstall-labs/ComfyUI-BS-Textchop ComfyUI-BS-Textchop
Then restart ComfyUI and find it under Add Node → BS-Nodes → Text. That's the entire install: no requirements.txt, no model downloads, no CUDA, nothing to place in a models folder. This is about the lowest-risk install in the whole custom-node ecosystem - the code imports nothing but the standard library. (Fun detail: it imports re and never actually uses it; the extraction is all plain str.find.) Given the pack has zero community chatter on reddit and the README still carries the placeholder YOUR_GITHUB_USERNAME in its clone command, treat it as an early hobby utility - useful, but not something with a big support base behind it.
Gotchas and troubleshooting
Where people get burned, it's almost always one of these:
- Markers are exact-match, whitespace included. If your text has
[END]with a trailing space, an end marker of[END]leaves that space sitting in the output. The node never trims anything. - First occurrence only. A marker that appears twice grabs the first match, not the last.
- Empty output. Nine times out of ten it's a case or whitespace mismatch between your marker and the text. Check both, then confirm you're reading the right pair's output -
extracted_text_2belongs to pair 2, and with ten identical-looking outputs it's easy to grab the wrong one.
Otherwise it behaves exactly like it says on the tin: a string in, slices out, no surprises.
Inputs (21)
| Name | Type | Default | Description |
|---|---|---|---|
| text | STRING | — | |
| start_marker_1opt | STRING | — | |
| end_marker_1opt | STRING | — | |
| start_marker_2opt | STRING | — | |
| end_marker_2opt | STRING | — | |
| start_marker_3opt | STRING | — | |
| end_marker_3opt | STRING | — | |
| start_marker_4opt | STRING | — | |
| end_marker_4opt | STRING | — | |
| start_marker_5opt | STRING | — | |
| end_marker_5opt | STRING | — | |
| start_marker_6opt | STRING | — | |
| end_marker_6opt | STRING | — | |
| start_marker_7opt | STRING | — | |
| end_marker_7opt | STRING | — | |
| start_marker_8opt | STRING | — | |
| end_marker_8opt | STRING | — | |
| start_marker_9opt | STRING | — | |
| end_marker_9opt | STRING | — | |
| start_marker_10opt | STRING | — | |
| end_marker_10opt | STRING | — |
Outputs (10)
| Name | Type | Description |
|---|---|---|
| extracted_text_1 | STRING | — |
| extracted_text_2 | STRING | — |
| extracted_text_3 | STRING | — |
| extracted_text_4 | STRING | — |
| extracted_text_5 | STRING | — |
| extracted_text_6 | STRING | — |
| extracted_text_7 | STRING | — |
| extracted_text_8 | STRING | — |
| extracted_text_9 | STRING | — |
| extracted_text_10 | STRING | — |