Load VAE

Load VAE is the node that loads the codec between pixels and the compressed latent space where diffusion actually runs. Its job is small and exact: give it a VAE file, it hands you a VAE object, and that object goes to VAE Encode (pixels → latents) and VAE Decode (latents → pixels). Everything that isn't that is where people go wrong, and there's a whole history of going wrong here.

The crucial framing, because it saves you a thousand threads: the VAE is not a color filter, and there are no universally "better" VAEs - there are only VAEs that match what a checkpoint was trained against. The famous grey-washed-output complaint was an SD 1.5 problem: most SD 1.5 checkpoints shipped expecting the external vae-ft-mse-840000-ema-pruned file (the "840k"), and without it, decode came out desaturated. Since then, the fix inverted completely. Modern checkpoints bake their VAE in, and attaching an external one is now the mistake. If your output looks washed out on a modern model, a missing VAE is almost certainly not why.

The mechanism

The vae_name dropdown is busier than it used to be. Files come from ComfyUI/models/vae, but the list also includes the small approximate "TinyVAE" preview decoders from models/vae_approx (taesd, taesdxl, taef1, and the video ones) - handy for fast low-res previews during sampling - and, as of the pixel-space wave, a literal pixel_space entry. That last one is worth knowing about: HiDream-O1 and friends diffuse on pixels directly and have no VAE at all, and people keep reporting those workflows as broken because they're "missing" this node. Nothing's missing. There's nothing to load.

Common issues, grounded in years of threads

• Grey/washed output on SD 1.5. Load the 840k. That's the one real, still-live VAE fix.
• Black output or NaN on SDXL in fp16. The original SDXL VAE overflows half precision. Use the sdxl-vae-fp16-fix file or force fp32 decode. Never reach for the flag that skips the NaN check - it hides the corruption rather than fixing it, and the black images keep coming.
• Attaching a VAE to a model that has one baked in. Illustrious-family fine-tunes explicitly say "the VAE is already integrated." Adding an external one degrades output. If a workflow loads a VAE and your model doesn't need one, that's your culprit.
• Chained img2img/inpaint passes grinding the image down. VAE encode/decode is lossy, and every round trip costs a little. The fix is to composite the edited region back onto the original pixels with ImageCompositeMasked, not to swap VAEs.

The 2026 twist

VAEs became a first-class criticism again: models sharing a latent format (Qwen-Image, Anima, Krea 2 all run Wan 2.1's encoder) let people swap in a different decoder to fix over-smoothing. That's a real lever, but it's an advanced one - the swap needs custom VAE loader nodes before a save node will accept the output. For the beginner, the durable advice is boring on purpose: load the VAE that matches the checkpoint, and if the model says it's baked in, leave this node out.

It ships with ComfyUI core. One input, one output, and an entire ecosystem's worth of folklore.