Text Replace

Somewhere in the middle of most prompt plumbing there's a find-and-replace. You've got a base prompt that works, and you want to sweep a colour, a material, a species, a location - one word changing while everything else stays put. Doing that by hand means editing a text box per test and hoping you didn't also change something else. Text Replace is a single node with a single line of rules and no regex homework.

The rules look like this:

green:red, orange:black

Find on the left, replace on the right, comma-separated. That's it. orange: with nothing after the colon deletes the word. If your find or replace contains a literal comma or colon, escape it as \, or \:. Newlines work as separators too if you'd rather have one rule per line.

Why "all at once" matters

The implementation applies every rule in one pass over the original text, not one rule after another. So this:

red:blue, blue:red

swaps red and blue. It does not turn everything blue, which is what a naive chain of two replacements would do, and which is the thing that quietly ruins a batch of test renders. Where two finds overlap, the longest one wins, so navy blue:teal beats blue:purple on the same text.

It's a small thing until you're generating thirty variants off a template and only notice the mistake in variant nineteen.

The two toggles

whole_words (on by default) means green leaves greenery alone. Leave it on for prompt work - prompt vocabulary is full of compounds where a substring match is wrong, and the failure is silent: you asked for red and got red-with-a-weird-thicket.

match_case (off by default) is the other direction. With it off, green also finds Green and GREEN, and the replacement follows the case it found - so Green becomes Red and GREEN becomes RED, not a shouty GREEN turning into a lowercase red. With it on, matching is case-sensitive and your replacement is written exactly as typed. Off is the sensible default; on is for when case is part of what you're matching (tag syntax, a proper noun you don't want swapped).

Output is one text socket. Wire it wherever the string was going - a CLIPTextEncode, another string node, a String Template Parser.

Where it fits

The obvious use is A/B sweeps: a fixed subject prompt, a rule line you edit between runs, fixed seed, compare. The subtler one is templating - keep the canonical prompt upstream, do the per-run substitution here, and the graph stays readable because the changes are visible in one small node instead of buried in a textarea.

It also does useful violence to LoRA trigger words. When a LoRA wants ohwx woman and your prompt style says something else, a rule line normalises it in one place. And deletion is genuinely handy: strip the masterpiece, best quality boilerplate out of an imported prompt before it reaches a modern model, where that vocabulary does nothing at best.

text is a forced input, by the way - it has to be wired from something, not typed in. That's deliberate: this is a pass-through in a chain, not a text entry box.

Install

comfy node install comfyui-nynxz-nodes

Or search Nynxz in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Nynxz/ComfyUI-NynxzNodes
cd ComfyUI-NynxzNodes
pnpm install && pnpm build

Restart. No dependencies - it's pure Python string handling, no torch involved, so this one works on any ComfyUI install including the ones where everything else in this pack is too new.

Small gotchas

A rule with no colon is skipped silently, which is fine until you've typed green red and wonder why nothing happened. The other one: deleting a word can leave a double space or a space before a comma, and the node tidies both - but it won't tidy a sentence that now reads oddly. That's on you.