CLIP Text Encode SDXL (Advanced)

This is the SDXL sibling of BlenderNeko's CLIP Text Encode (Advanced). Same idea - pick how prompt weights get interpreted, including the A1111-matching mode - but built for SDXL's two text encoders instead of SD 1.5's one. If you're on an SDXL, Pony, Illustrious, or NoobAI checkpoint and you want that same control over up/down-weighting, this is the version that fits.

Worth being upfront: the README itself says this node "mainly exists for experimentation," and it's honest about that. For most SDXL work you don't strictly need it. It earns its place when you're chasing A1111 parity on an SDXL model, or when you want to play with the two-encoder split by hand.

The SDXL wrinkle: two encoders

SDXL doesn't run one CLIP, it runs two - CLIP-L and the bigger OpenCLIP-G - and combines their outputs. That's where its extra grip on composition and lighting comes from. Most of the time you feed both the same prompt and never think about it. This node splits them out so you can send different text to each, plus it adds a slider to trade off how much each one contributes.

That's genuinely niche. It's the SDXL analog of the trick people use on Flux, where tags go to CLIP-L and natural language goes to T5. On SDXL the payoff is smaller and more of an experiment, which is exactly how the README frames it.

The inputs and outputs that matter

Two text boxes and one slider are the SDXL-specific part; the two dropdowns are shared with the SD 1.5 version:

• text_g and text_l - your prompt for the OpenCLIP-G encoder (text_g) and the CLIP-L encoder (text_l). Put the same text in both to behave like a normal encode. Split them only if you're deliberately experimenting.
• balance (0.0–1.0, default 0.5) - the tradeoff between the two encoders. At 0.0 the conditioning is pure CLIP-L (OpenCLIP-G zeroed out); at 1.0 it's pure OpenCLIP-G (CLIP-L zeroed out). 0.5 is the neutral middle. This is a dial to explore, not one you need to touch for good results.
• weight_interpretation - same five options as the non-SDXL node: comfy, A1111, compel, comfy++, down_weight. A1111 is the one to pick if you're matching an Automatic1111 render.
• token_normalization - none, mean, length, length+mean. For A1111 parity, pair none with the A1111 interpretation.

The output is a single CONDITIONING that wires into the positive or negative input of your KSampler, same as any encode node.

One thing this node does not do: it doesn't set SDXL's size/crop conditioning (the width/height/target values that ComfyUI's built-in CLIPTextEncodeSDXL bakes in). If you care about those, chain Add CLIP SDXL Params onto this node's output - that's the intended pairing from the same pack.

Installing it

ComfyUI Manager: search Advanced CLIP Text Encode, install, restart.

Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/BlenderNeko/ComfyUI_ADV_CLIP_emb

Restart ComfyUI, hard-refresh (F5). No model files, no extra dependencies - it operates on the CLIP you already loaded. Installing the pack gives you this node, the SD 1.5 version, and the two SDXL params nodes together.

Where people get tripped up

Feed it an SDXL CLIP, not an SD 1.5 one. This node expects the dual-encoder CLIP that comes out of an SDXL checkpoint loader. Hand it an SD 1.5 CLIP and it won't do what you want - use the plain CLIP Text Encode (Advanced) for those models.

Weighting is a CLIP-era feature. SDXL and its fine-tunes (Pony, Illustrious, NoobAI) all use CLIP, so weighting works here. But if you've drifted onto a 2026 LLM-encoded model (Z-Image, Flux 2, Anima), the whole weighting concept is dead at the encoder and no version of this node revives it. This is a tool for the SDXL lineage.

Don't overthink balance and the split text. The README calls this node experimental for a reason. If you fill both text boxes identically and leave balance at 0.5, you've got a normal SDXL encode with A1111-style weighting - which is 95% of why anyone installs it. The split-encoder stuff is a rabbit hole you can skip until you have a specific reason.