Dart Ban Tags From Regex

Dart Ban Tags From Regex is how you tell the Dart model "don't ever generate anything matching this pattern" - using actual regular expressions instead of listing out every possible tag by hand. It's a small node with one job: turn a list of regex patterns into the ban_tags string that Dart Generate or Dart Generate(Advanced) takes as an optional input.

Ban tags vs. remove tags - they're not the same thing

This is the part worth understanding before you use it, because the Dart nodes give you two different-looking ways to keep a tag out of your output, and they work at different points in the pipeline. remove_tags (a plain string input on the regular Dart Generate node) is a post-filter - the model generates freely, and matching tags get stripped from the finished output afterward. ban_tags, which is what this node feeds, works earlier: it's meant to steer the generation itself away from those tags in the first place, rather than cleaning them out after the fact. If you want a tag to simply never show up regardless of what else the model tries, ban_tags from this node is the more direct route; remove_tags is closer to a cleanup pass on output you're mostly happy with.

What it actually takes

One required input beyond the obvious tokenizer (DART_TOKENIZER, from Dart Load - the node needs it to know the tag vocabulary it's matching patterns against): patterns, a multiline string field defaulting to .+ hair. That default is a good example of the point of this node - instead of hand-listing every possible hair-color and hair-style tag (brown_hair, long_hair, twin_tails, and dozens more), one regex catches the whole family in one line.

The README spells out the mechanics: split multiple patterns across separate lines, and it searches with all of them. So a patterns field like:

.+ hair
.+ eyes

bans every tag ending in hair and every tag ending in eyes in one node, rather than two.

The single STRING output wires into ban_tags on Dart Generate or Dart Generate(Advanced).

Installing it

Install through ComfyUI Manager (search "ComfyUI-Dart") or clone manually: cd ComfyUI/custom_nodes && git clone https://github.com/nkchocoai/ComfyUI-Dart.git, then restart ComfyUI. It's bundled with the rest of the pack, so there's no separate install and no model download involved - this node is pure pattern matching against the tokenizer's vocabulary, no inference happens here.

Where this trips people up

The most common mistake is writing patterns that are broader than intended. .+ hair looks specific, but remember it's matching against a large, ungoverned tag vocabulary - if you're not careful with anchoring, a loosely written pattern can catch tags you didn't mean to ban. Test with a narrow pattern first and widen it once you've confirmed it's only catching what you expect, rather than starting broad and hoping for the best.

The other one is confusing this with remove_tags and wondering why banning .+ hair here didn't stop a hair-color tag that slipped through - if you wired your pattern into the wrong input, or used both ban_tags and remove_tags for overlapping purposes without meaning to, it's worth checking which input actually got which string. They solve a similar-sounding problem from opposite ends of the generation.