String Extract Keywords

Worth being upfront about this one: the node's display name and its actual class name tell two different stories, and there's no description field to settle the disagreement.

The class name is string_clear_if_contains - read literally, that's "clear/blank the text if it contains one of these keywords," a filter or censor node. The UI's display name, "String Extract Keywords," implies the opposite: pull the matching keywords out rather than blank the whole string. I can't execute the node to confirm which one is actually correct, so this article leans on the class name as the stronger signal - it's the literal function name the author wrote, whereas display names in this pack have a track record of drifting from what the code does (see the emoji-and-marketing-language display names elsewhere in comfyui-sortlist). Verify against a quick test with your own text before wiring this into anything that matters.

The inputs and outputs that matter

• text - the STRING to check.
• filter_keywords - STRING, default "man\nwoman" (newline-separated). The default reads like a leftover from testing a gender-word filter rather than a general-purpose default - replace it with your own list before using this for real.
• case_sensitive - BOOLEAN, default false.

One output: output - the STRING, either cleared or filtered, per whichever behavior the node actually implements.

Installing it

ComfyUI Manager: search comfyui-huyl2-nodes, install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/huyl3-cpu/comfyui-sortlist

restart. Not documented in the pack's README. Pure string matching, no dependencies beyond a working Python install.

Common issues & troubleshooting

The naming ambiguity above is the whole troubleshooting story for this node. If your pipeline behaves the opposite of what you expected - text you thought would pass through unchanged got blanked out, or text you expected to be filtered came through intact - that's almost certainly this exact disagreement between class name and display name, not a bug. Run it once on a short known string containing one of your filter_keywords terms and look at output directly before trusting it anywhere downstream of a real pipeline, especially if this is gating content going into a public-facing workflow.

Beyond that: filter_keywords splits on newlines, so if you're building the list dynamically from another node rather than typing it into the widget, make sure whatever's feeding it actually uses \n as the separator - a comma-separated list, for instance, would likely be read as a single (very unlikely to match) keyword instead of several.