Load CLIP Vision

Load CLIP Vision is the sibling of Load CLIP that nobody explains, and it's easier to understand than it looks: it loads the vision half of CLIP. The regular CLIP you already know turns your text into vectors. This one turns a picture into vectors - a neural network trained to understand images the way CLIP-L understands words. It's how a workflow makes an image legible to a model that otherwise only reads text and latents.

You'll find it in two very different kinds of workflows, and knowing which is which saves you a lot of head-scratching.

The two jobs

Image-to-video. This is the big one. Stable Video Diffusion and the other img2vid checkpoints work by running your starting frame through a CLIP vision model, and this loader provides exactly that. The graph is: Load Checkpoint Image Only → gives you MODEL, CLIP_VISION, and VAE; this node is the standalone way to get that same CLIP_VISION wire when your model isn't the all-in-one img2vid checkpoint. From there SVD_img2vid_Conditioning takes the vision output plus your image and builds the conditioning that drives the video sampler.

Reference conditioning. The SD 1.5/SDXL era used CLIP vision output to inject a reference image's content - this is the engine behind IP-Adapter's style and identity transfer. The pattern there is Load CLIP Vision → CLIP Vision Encode → the adapter node that fuses the image embedding into conditioning.

One honest caveat from the 2026 landscape: the reference-image job did not survive the architecture shift. IP-Adapter never got a proper Flux-era successor, and appearance-transfer work moved to edit models and in-context reference conditioning. So on a modern base, the most likely reason you're here is video. On SDXL, it's style. The node itself doesn't care - it just encodes.

The mechanism

Single input: clip_name, listing files in ComfyUI/models/clip_vision. It loads through ComfyUI's vision-CLIP loader and hands you one CLIP_VISION object. That object is then consumed by encoding nodes - CLIP Vision Encode (which has a crop choice of center or none, relevant for whether the encoder crops your image to its expected square) or the img2vid conditioning node. The file you want is usually the vision encoder that shipped alongside your video or reference workflow, and it's small - hundreds of MB, not gigabytes.

What trips people up

• Vision CLIP is not text CLIP. A CLIP_VISION wire will not connect to a CLIP Text Encode node, and a text encoder file won't show up in this dropdown. The folder (clip_vision vs text_encoders) is the tell.
• Wrong vision model = wrong conditioning. An SDXL-era vision model and a video-specific one are different checkpoints; a mismatch produces conditioning that looks fine and behaves wrong. Use the one the workflow names.
• The image side needs preprocessing. This node only encodes. If your workflow feeds a raw screenshot where the model expects a clean square crop, you get the crop behavior you picked - or noise.
• Modern workflows may not need it at all. If a shared workflow has no CLIP Vision node and the model is a 2026 edit/DiT base, that's probably correct, not broken.

It ships with ComfyUI core - one line, no install. It's a quiet node that does exactly one thing, and once you know whether you're doing img2vid or reference conditioning, the whole graph around it makes sense.