BadmanCLIPTextEncodeSDXLRegion

Here's a node with an honest confession baked right into its own README entry: it was built for a specific purpose, and the author tells you upfront that the purpose doesn't really pan out on SDXL. That's rare enough to be worth respecting, and worth understanding before you wire this in.

What it's for, and the catch

The pack's own description says this is an SDXL conditioning node intended for use with CutOff - "sadly SDXL does not do too well with CutOff." CutOff is an older SD 1.5-era extension for a specific, annoying problem: attribute bleeding within a single prompt, where "red hair, white dress" can leak "red" into the dress because CLIP conditioning doesn't cleanly separate which word modifies which noun. CutOff's whole trick is isolating a term's influence to its intended region of the prompt. The catch, and it's a real one, not just a personal opinion - community reports on trying to get CutOff working on SDXL land on the same explanation independently: CutOff was built against SD 1.5's single CLIP encoder and its specific tokenization, and SDXL runs two CLIP encoders on different layers with different tokens for the same words. Ask CutOff to isolate "red" on SDXL and it's often hunting for a token that isn't even the one SDXL is using for "red" in that context, so the technique mostly falls flat. This node exists as an attempt to bridge that gap; the author's own verdict is that it doesn't fully close it.

So go in with the right expectations: this is worth trying if you're specifically fighting attribute bleeding on an SDXL checkpoint and you're willing to experiment with CutOff alongside it, not a drop-in fix you can wire and forget.

What it actually outputs

Set that context aside and the node itself is a fairly conventional SDXL text encoder, structurally close to ComfyUI's own native CLIPTextEncodeSDXL. It takes clip, two text fields - text_g (the coarser, "global" caption feeding SDXL's larger text encoder) and text_l (the more detailed caption feeding the smaller one) - plus SDXL's own size-conditioning metadata: width/height (the image's original size, part of how SDXL was trained to condition on training-crop metadata), crop_w/crop_h (crop-offset conditioning), and target_width/target_height (the size you're actually generating at). All six size fields default to 1024 (crop fields default to 0) and accept 0–4096.

Where it diverges from the native node is the output: instead of a plain CONDITIONING, you get a CLIPREGION - a custom type meant to hand off into a region-aware conditioning combiner like CutOff's own nodeset, rather than straight into a KSampler.

Installing it

ComfyUI Manager: search ComfyUI-BadmanNodes, install, restart. Manual: cd ComfyUI/custom_nodes && git clone https://github.com/MariusKM/ComfyUI-BadmanNodes. No extra dependencies for this node itself, but to actually use its intended workflow you'll separately need ComfyUI_Cutoff installed too - this node produces a CLIPREGION, and that type only means something once something downstream is built to consume it.

Where people get burned

The first trap is trying to wire CLIPREGION straight into a sampler expecting CONDITIONING - it won't connect, because it isn't the same type; you need the CutOff-side node in between to turn a region into usable conditioning. The second, bigger trap is going in expecting SDXL-CutOff to behave like CutOff does on SD 1.5. It won't, for the tokenization-mismatch reason above, and no amount of fiddling with crop_w/crop_h changes that underlying encoder mismatch. If attribute bleeding is your actual problem on SDXL, it's worth weighing this against alternatives before sinking time into it - spatial regional-prompting techniques (masking conditioning per canvas area rather than per prompt attribute) are a different tool for a related symptom and tend to be better maintained for SDXL-era models than CutOff ports are.