VAE Encode

If you've ever img2img'd, inpainted, or hi-res fixed, you've used this node without thinking about it. VAEEncode takes pixels and turns them into the compressed representation diffusion actually runs on. It's the front door to latent space, and unlike most nodes in this family, it has exactly two inputs and exactly one job.

What it does

A VAE is the codec between images and the latent world: it squeezes a 1024x1024 image down to something like 128x128 (an 8x spatial downscale on SD-class models, with 4–16 channels depending on the architecture), then the sampler does its thing in that compressed space. VAEEncode is the "in" direction. VAEDecode is the "out." Every image-to-image chain, every inpaint mask, every two-pass upscale starts by encoding.

The only two knobs that matter

• pixels - your IMAGE. Any size the VAE can handle; 64x64 minimum, multiples of 8 are polite.
• vae - the VAE model. This is the one decision that matters, and it's a decision people get wrong constantly. The VAE must match the checkpoint's latent space: channel count, scaling, everything. SD 1.5's shipped VAE was famously washed-out and everyone swapped in a fixed one; that history convinced a generation that "a better VAE" is a thing to install. On modern models it's the opposite - the checkpoint bakes its own VAE in, and bolting on a stranger's is how you get noise or flat color instead of an image. If you're encoding, use the VAE your model was trained against.

Output is a single LATENT, and it wires straight into a KSampler. For img2img you'd set the sampler's denoise below 1; for inpainting you'd typically route through VAEEncodeForInpaint or add a SetLatentNoiseMask after this node.

How it works, mechanically

Under the hood it's one call: vae.encode(pixels), wrapped in a LATENT dict. There are no hidden parameters, no strength, no blend mode. All the control lives in the VAE you hand it. That's the whole node - which is why people who overthink it get into trouble.

Common issues

Wrong VAE is failure mode number one: mismatched channel counts produce pure static or flat color on decode, not a subtly wrong image. If your encode-then-decode round trip looks crusty, it's usually not the VAE - every encode/decode cycle costs a little fidelity, which is why chained img2img passes grind detail down over time. And for very large inputs, plain encode can eat VRAM; that's what VAEEncodeTiled exists for. For anything under that, this is the node you want, and it's been sitting in your node list since day one.