Load CLIP

Every prompt you've ever typed went through a node like this before the diffusion model laid eyes on it. Load CLIP is the text-encoder loader: it loads the neural network that turns your words into the conditioning vectors the denoiser actually conditions on. The diffusion model doesn't read English. CLIP does, and this node is how the two talk.

You reach for it whenever your workflow uses a single text encoder. That covers more architectures than you'd think: plain SD 1.5 and SDXL use the small CLIP-L file, Stable Cascade wants CLIP-G, and the video crowd loads Wan's UMT5-XXL, Mochi's T5-XXL, or LTXV's T5 here too. If a model needs two encoders at once - SDXL, Flux, SD3 - you want its sibling DualCLIPLoader instead, because that node bundles the pair into one CLIP object. Load CLIP is the single-encoder version.

The mechanism

Pick a file from the clip_name dropdown and it loads that safetensors from ComfyUI/models/text_encoders (the old models/clip folder is still watched too). Then pick a type. That's the whole node, mechanically. The type dropdown - about 25 entries and growing - is not cosmetic. It tells ComfyUI which encoder architecture it's dealing with so the prompt is tokenized and structured the way that encoder was trained. Get it wrong and you get either an outright load error or, sneakier, a prompt that's technically encoded but semantically scrambled.

The official recipes, from the node's own description, read like a lookup table:

• sd: clip-l
• stable_cascade: clip-g
• sd3: t5 xxl / clip-g / clip-l
• mochi, cogvideox, cosmos: t5 xxl
• wan: umt5 xxl
• hidream: llama-3.1 (recommended) or t5
• omnigen2: qwen vl 2.5 3B
• lens: gpt-oss-20b
• pixeldit: gemma 2 2B elm

One file, many architectures: the same t5xxl_fp8_e4m3fn.safetensors gets loaded with type=sd3 for SD3.5 and type=mochi for Mochi, and it matters which you pick. The third input, device, defaults to default and offers cpu as an advanced option - a genuinely useful escape hatch when a big LLM-style encoder (Gemma, Qwen, the newer ones) won't fit on the GPU and you're fine letting it run slowly on the CPU.

The single output, CLIP, wires into CLIP Text Encode (Prompt) to produce the CONDITIONING your sampler consumes. That's the whole journey: Load CLIP → CLIP Text Encode → KSampler.

What trips people up

The "why is my Flux prompt behaving like an SD prompt" class of bug is usually this node misconfigured or the wrong one for the job. Three things to check before anything else:

• The type must match the model, not the file name. t5xxl loaded as sdxl is a great way to generate garbage confidently.
• Many 2026 models have moved to LLM text encoders (Qwen, Gemma, Llama) where CLIP tags and prompt weighting like ((text:1.4)) do nothing. That's not this node misbehaving; the encoder genuinely reads natural language, not tags.
• Big encoders are the VRAM hog. A 12B Gemma in fp16 is over 22GB on its own. If you're OOMing at load, grab a quantized (fp8/GGUF) encoder build rather than fighting the full one.

It ships with ComfyUI core - no Manager, no install. Drop the right file in models/text_encoders, set the type, and you're done. The one habit worth building: when you copy a workflow for a model you haven't run before, look at this node's type dropdown first. It's the cheapest possible check, and it's wrong in a surprising number of shared workflows.