CLIP Text Encode (Advanced)

If you've ever ported a prompt from Automatic1111 to ComfyUI and gotten a subtly different image - same seed, same model, same everything, but the emphasis lands wrong - this is the node that fixes it. ComfyUI and A1111 interpret (word:1.3) differently at the math level, so (masterpiece:1.4), (bad hands:0.7) doesn't hit the same in both. Swap in CLIP Text Encode (Advanced), set it to the A1111 interpretation, and your old prompts behave the way you're used to. That's the headline use, and it's why people find this node.

But it's really a knob box for how prompt weights get applied, and there's more in it than the A1111 toggle.

Why weighting even differs

A weight like (dog:1.3) isn't a volume dial the model reads directly - it's an instruction to nudge the text embedding, and there's more than one reasonable way to do that nudge. Stock ComfyUI lerps your embedding toward a completely empty prompt; A1111 just scales the vector by its weight; compel does something cleverer for down-weighting. Same number, different geometry, different picture. This node exposes those methods as a dropdown instead of baking one in - it changes how weights become conditioning, not what you prompt.

The two settings that matter

Everything else on the node (the text box, the clip input) works exactly like the normal CLIP Text Encode. The two dropdowns are the whole point:

• weight_interpretation - how up/down-weighting is handled. comfy is the default ComfyUI behavior (lerp toward an empty prompt - effective but aggressive). A1111 scales vectors by their weight, matching Automatic1111. compel mixes masked embeddings so down-weighting actually removes a concept's influence instead of just shrinking one token. comfy++ blends comfy-style up-weighting with compel down-weighting, and is gentler than plain comfy. down_weight rescales so nothing ever goes above 1.0 - you only ever subtract.
• token_normalization - how the raw token weights get normalized before any of that. none leaves them alone. mean shifts things so the average meaningful token sits at 1.0. length spreads a multi-token word or embedding's weight across its tokens so a long word doesn't get accidentally over-weighted. length+mean does both.

For the "match A1111" job, the combo people actually use - confirmed in the wild - is token_normalization: none and weight_interpretation: A1111. That's the pairing that makes a ComfyUI graph line up with an A1111 render.

The output is a single CONDITIONING, and it plugs straight into the positive (or negative) input of your KSampler exactly where a normal CLIP Text Encode would. Nothing downstream changes.

The interpretations, in practice

Down-weighting is where these methods genuinely diverge, and it's worth knowing why. When you write (palmtrees:0.3), the tokens for "palmtrees" bleed context into the entire prompt embedding, so with plain comfy or A1111 you can crank the weight way down and still get a beach full of palm trees. Compel's trick is to build separate embeddings - one with the word, one with it masked out - and mix them by the weight, so 0.3 really means 0.3 of that concept's influence across the whole image. If down-weighting things out has been frustrating you, compel or comfy++ is the reason to reach for this node beyond the A1111 stuff.

Fair warning: this is a fiddly, taste-driven tool, and the difference between comfy++ and compel is the kind of thing you A/B on a fixed seed, not something you'll intuit from the names. Most people set it once for A1111 parity and never touch the other modes.

Installing it

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

Manually:

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

Restart ComfyUI and hard-refresh the browser (F5). No model downloads, no requirements.txt, no heavy dependencies - it's pure logic operating on the CLIP you've already loaded, so it's about as safe an install as custom nodes get. BlenderNeko is one of the OG ComfyUI authors (he also wrote the early ComfyUI node docs and the Noise/unsampling pack), so this isn't some sketchy one-off.

Where people get tripped up

Weighting only works on CLIP models. This node operates on CLIP embeddings, which is what SD 1.5 and SDXL use. On 2026-era models with an LLM text encoder (Z-Image, Flux 2 Klein, Anima), prompt weighting is disabled at the encoder level entirely - the (word:1.4) syntax gets passed through as literal punctuation and does nothing useful. This node can't bring it back. It's an SD 1.5 / SDXL tool, full stop.

Syntax still has to be right. Even in A1111 mode, ComfyUI needs the colon: (dog:1.1), not dog1.1. A malformed weight silently reads as plain text.

A1111 parity is close, not pixel-identical. Composition can still drift because samplers and RNG differ between the two apps. Matching the weight interpretation removes the biggest difference; it doesn't make them the same program.