CLIP Text Encode (SDXL Refiner)

Quick honesty check before we start: the SDXL refiner is the most ignored model in the entire SDXL lineup. Stability shipped it as a second pass meant to add fine detail - skin texture, micro-contrast - after the base model rendered the scene, and then the community collectively shrugged. Fine-tuned checkpoints got good enough that nobody wanted to wait for a second generation. One CivitAI creator put it as "an added step that never added much," and that's the polite version. So if you're here because a downloaded workflow has this node in it, the first thing to know is that the node is not the problem and it's not the point - it's just the prompt encoder for a model most people decided not to use.

What it actually does

The refiner's text encoder is not the same CLIP as the base SDXL model uses. It's the refiner-specific OpenCLIP-G path, and the interesting part is what it adds to the encoding: an aesthetic score. That's the ascore input, defaulting to 6.0 with a range that runs all the way to 1000. It's a single number that tells the refiner how "aesthetically pleasing" the image is supposed to be, and it gets stuffed into the conditioning's pooled output alongside width and height - so the refiner model knows not just what you prompted, but what resolution you're working at and how pretty you want it.

The encoding itself works like any other CLIP encode: your text gets tokenized and run through the refiner's encoder, and out the other end comes a single CONDITIONING tensor. Wire that into a KSampler that's running the refiner checkpoint (sd_xl_refiner_1.0.safetensors, which lands in ComfyUI/models/checkpoints), typically at low denoise - 0.2 to 0.4 - on the same latent the base pass produced.

The inputs that matter

• ascore - the aesthetic score. Default 6.0. This is the dial nobody agrees on. Values in the 5-7 range are the sane zone; crank it toward 10 and the refiner starts chasing "beautiful" hard enough to fight your prompt. There's no reason to touch it unless you're deliberately tuning for detail.
• width / height - just tell the encoder the generation resolution. Match them to what the sampler is producing, or the refiner's positional expectations get confused.
• text - your prompt. Note the refiner path usually runs an empty-ish negative with the score doing the steering; you don't need a long negative prompt here.

How you get it and what you're loading

It ships with ComfyUI core - no install, it's right there in the "CLIP Text Encode (SDXL Refiner)" menu. What you need is the refiner model file itself. ComfyUI won't grab it for you; download sd_xl_refiner_1.0.safetensors from HuggingFace into models/checkpoints (or use the SDXLRefinerLoader-style loader in a dual-loader workflow).

Should you bother?

Honestly, mostly no. The era where the refiner was worth a second pass is over; today's SDXL fine-tunes baked that detail in at training time. The two legitimate reasons this node survives in the wild: you inherited a workflow that uses a base→refiner chain and you want to keep it byte-compatible, or you're doing a hi-res fix where the refiner's latent-focused second pass genuinely helps at low denoise. If you do run it, keep ascore modest and the denoise low - a refiner at high denoise will happily overwrite the composition your base model just nailed, and the "fix" becomes the failure.