VAELoader KJ
A VAE loader for pixel-space models
- VAE
At a 7.81% click-through, this little loader punches above its size - and that's because it solves a specific, confusing problem: what do you plug into your VAE Decode node when the model you're running doesn't have a VAE? Its vae_name dropdown has exactly one option, pixel_space, which is the tell. This is a VAE loader built for the wave of pixel-space models that arrived in 2026.
The problem it solves
Almost every model since SD 1.5 diffuses inside a compressed latent and hands the result to a VAE to turn back into pixels. Pixel-space models - HiDream-O1, and the various no-VAE conversions like L2P - delete that step and diffuse directly on pixels. Great for editing (no compression loss compounding across passes), but it breaks a fundamental assumption in ComfyUI graphs: everything downstream expects a VAE to decode with. The most common way people meet a pixel-space model is by loading a workflow, seeing no VAE loader, and reporting the thing as broken. There's nothing to load - there's no VAE.
VAELoaderKJ gives you a stand-in. Pick pixel_space and it hands you a VAE object that satisfies the graph - the decode step passes the pixels through instead of running a real autoencoder - so the rest of your workflow wires up normally. It's the adapter that lets a no-VAE model live in a VAE-shaped pipeline.
Inputs and outputs
Three settings, one output:
- vae_name - the choices your install exposes; here,
pixel_space. This is the whole reason the node exists. - device (
main_deviceorcpu) - where the VAE lives. CPU keeps it off your GPU if you're tight on VRAM. - weight_dtype (
bf16,fp16,fp32) - the precision it loads at.
Output is a VAE, which goes straight into your VAE Decode (or wherever your workflow expects one).
Where it fits
Anywhere you'd normally drop a VAE Loader, but for a model that shipped without one. If you're on a standard latent model - SDXL, Flux, Wan - you don't need this; use the stock VAE loader with the model's matching VAE file. VAELoaderKJ earns its keep specifically in the pixel-space corner of the ecosystem, which is still experimental but was one of the defining architecture threads of early 2026.
Installing it
Bundled in kijai's KJNodes pack.
- ComfyUI Manager - search KJNodes for ComfyUI, install, restart.
- Manual -
cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, thenpip install -r requirements.txt, and restart.
Common issues
The confusion cuts both ways. If you're troubleshooting a pixel-space workflow that "looks incomplete," stop hunting for the missing VAE file - this loader is the answer, and there's no external download that goes with pixel_space. Conversely, if you grabbed this node for a normal latent model, it's the wrong tool: your model has a real VAE, and passing pixels through unchanged will give you garbage out of the decode.
One more thing worth knowing about the neighborhood: pixel-space generation is genuinely slow - compute scales with pixel count, which is the exact reason latents were invented in the first place. So if you're using this loader, the slowness you're feeling is the model architecture, not the node. And the decoder-swap alternatives (like Nvidia's PiD) that keep a latent and only replace the decoder are a different beast - those can hallucinate detail, so don't treat any of this as a lossless drop-in.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| vae_name | COMBO | 1 options: pixel_space | |
| device | COMBO | 2 options: main_device, cpu | |
| weight_dtype | COMBO | 3 options: bf16, fp16, fp32 |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| VAE | VAE | — |