CLIP Text Encode (SDXL)

Here's the thing to know before anything else: this isn't a BMAB-specific node. CLIPTextEncodeSDXL is ComfyUI's own built-in SDXL text encoder - the same one that ships with core ComfyUI and shows up whenever you build an SDXL graph from a template. The comfyui_bmab pack doesn't reimplement it or add anything to it; it just appears under the pack's node listing because BMAB's example workflows use it, and once a node type is registered, ComfyUI will happily show it wherever it's referenced. If you already know the core node, you already know this one - nothing here changes because BMAB is installed.

Why SDXL needs a different encoder at all

Regular CLIPTextEncode only knows your prompt text. SDXL's own architecture was trained with extra conditioning - the resolution it was generated at, and a crop offset - baked in alongside the text embedding, because Stability trained it on a mixed-aspect-ratio dataset and needed the model to know "this image was cropped from a bigger one starting at (x, y)." Skip that conditioning and SDXL still works, but you're leaving information on the table the model was trained to expect.

SDXL also runs two text encoders in parallel - CLIP-L and OpenCLIP-G - and combines their output. That's why this node has two prompt fields instead of one.

The inputs that matter

• text_g and text_l - your actual prompt, split across the two encoders. In practice most people just put the same prompt text in both; some workflows put a shorter, tag-style prompt in text_l and a fuller natural-language description in text_g, since the two encoders were trained on somewhat different caption styles.
• width / height (default 1024 each) and target_width / target_height (default 1024 each) - the resolution conditioning. Leave these matching your actual generation size unless you're deliberately doing something unusual with SDXL's crop-conditioning behavior.
• crop_w / crop_h (default 0) - the crop-offset conditioning. Zero means "this is the full, uncropped image," which is what you want essentially always.
• clip - your CLIP model, from whatever checkpoint loader feeds the rest of your graph.

Output is a single CONDITIONING, which wires straight into your KSampler (or, in a BMAB workflow, into a BMAB Integrator node that packages it alongside model/vae/seed into a bind).

Installing it

You get this node for free with any working ComfyUI install - it needs nothing extra. If you're here because you're setting up comfyui_bmab specifically, the pack itself installs via ComfyUI Manager (search comfyui_bmab) or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/portu-sim/comfyui_bmab.git
cd comfyui_bmab
pip install -r requirements.txt

plus the two companion packs the README calls for - comfyui_controlnet_aux and ComfyUI_IPAdapter_plus - though neither is required to use this specific node.

Where people get confused

The main trap is assuming there's CLIP-skip logic hiding in here somewhere, since SDXL and CLIP skip get mentioned in the same breath a lot. There isn't - SDXL's checkpoint loader already conditions both encoders on the penultimate CLIP layer by default (what A1111 calls "CLIP skip 2"), before this node even runs. This node has nothing to do with that; it's purely the prompt-plus-resolution encoder. The second trap is leaving target_width/target_height at a different value than your actual output resolution out of habit from an old template - SDXL uses the mismatch as a signal, so if you're not deliberately exploiting that, keep them matched to what you're actually generating.