Match Text

Match Text (RegexMatch) answers one question: does this string contain something shaped like this pattern? Yes or no, true or false, no extraction, no replacement - just a boolean you can route. It's the decision-maker of the regex family, and it's the node you reach for when a workflow needs to branch on what its text contains.

Where this shines is conditional logic. You've got an LLM output and you need to know whether it actually returned JSON before you try to parse it - pattern ^\{.*\}$ and branch on the result. A downloaded prompt that might contain attention-weight syntax \([^)]*\) - check first, then clean only if present. A filename that may or may not contain a date. ComfyUI's boolean outputs feed directly into switch/router logic, so a "does it match?" node is how you make a graph decide instead of just computing. It's also the cheap, non-destructive alternative to running RegexReplace and diffing the result - much cleaner.

How it works

Under the hood it's Python's re.search(pattern, string, flags), and the output is True if a match is found anywhere in the string - note it's search, not match from the start: the pattern can match in the middle of the text. The regex_pattern input is the pattern; the flags are the usual trio:

• case_insensitive - defaults to true. The family-wide default that catches people: "dog" will match "Dog."
• multiline - off by default, for ^/$ at line boundaries.
• dotall - off by default, so . won't cross newlines.

Output is a single BOOLEAN named matches. True, the pattern matched somewhere; false, it didn't. That's the whole node.

One example to make it concrete: you want to gate an upscale path on whether a filename came from a particular run. Pattern ^img_[0-9]+_ matches only when the string starts with an image-style identifier, so False on anything else, and your router picks the other branch. No extraction, no side effects, just a yes/no your graph can act on.

Common issues

The deliberate design decision worth knowing: an invalid regex returns false, not an error. A typo like [ unclosed doesn't crash the graph - it just says "no match," which is friendly for automation but a silent killer for debugging. If a branch is never triggering, check the pattern itself for validity rather than assuming the text. Second gotcha: "contains anywhere" semantics - if you need "the whole string is this pattern" (anchored), you have to write the anchors yourself with ^...$. And the case-insensitive default: if your match is working when it shouldn't, that toggle is almost always the culprit. Pair it with the Compare Text node and you've got two clean boolean sources - one pattern-based, one literal - to feed your routing logic.