CLIP Text Encode (Prompt)
The node your whole workflow starts at
- clip
- CONDITIONING
Every image you've ever made in ComfyUI started here. CLIP Text Encode is the node that turns your prompt into conditioning - the numerical embedding the diffusion model cross-attends to while it draws. No prompt box is magic; this is the machinery under it. Type text, plug in a CLIP, and out comes a CONDITIONING that goes to your KSampler's positive (and a second copy, with your negative prompt, to the negative input).
It's the node beginners see first and experts never stop using, because "how do I write this prompt" is really "how do I encode this prompt." And in 2026 that question changed: which encoder the CLIP holds decides everything about what your prompt words can do.
How it works
The CLIP input is the text encoder loaded with your checkpoint (or separately for models that split encoders). The node tokenizes your text, runs it through the encoder, and returns the embedding. It's one step in the pipeline - the text encoder is a whole separate neural network that runs before the diffusion model, and "CLIP" is a generic name for whatever encoder the model trained with: classic CLIP ViT-L/14 on SD 1.5, OpenCLIP-G on SDXL, T5 on Flux and SD3.5, an LLM like Qwen3 or Mistral on the newest models.
Two inputs, both obvious: text (multiline - your whole prompt) and clip. One output, CONDITIONING, which feeds positive or negative. That's the whole interface, and it's the whole reason ComfyUI is composable: encode twice, wire both into a KSampler, and you've got classifier-free guidance.
What actually changed (this matters)
The rules you learned on SD 1.5 don't all transfer. On guidance-distilled models running at CFG 1, the negative prompt box is inert - there's no unconditional pass for it to steer, so a second CLIPTextEncode fed to negative does nothing. The community's consistent advice: write constraints as presence ("clean studio background, sharp focus") instead of negatives.
And the encoder's vocabulary is real. masterpiece, best quality is SD 1.5/XL vocabulary that does almost nothing on LLM-encoded models; a T5 or Qwen encoder was never trained on it, and every token it eats is budget taken from your actual description. If you're on Flux, write natural language; if you're on an anime SDXL derivative, tags still work because the model was trained on them.
Where people get burned
- The "CLIP is None" error. The CLIP input is missing or your checkpoint has no text encoder. This node raises a specific error telling you exactly that - usually a loader problem, not a text problem.
- Truncation. Classic CLIP caps at 77 tokens; longer prompts get cut. T5/LLM encoders handle long text natively - another reason prompting style is encoder-specific.
- Prompt weighting. Weighted syntax like
(word:1.2)works on some encoders and does nothing on others. On T5/LLM encoders it's typically ignored; don't build a workflow around it without testing.
Ships with ComfyUI core since day one. There's no installing this - there's only writing better prompts, which now means knowing which encoder you're talking to.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| text | STRING | The text to be encoded. | |
| clip | CLIP | The CLIP model used for encoding the text. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CONDITIONING | CONDITIONING | A conditioning containing the embedded text used to guide the diffusion model. |