Inpainting lets you regenerate one part of an image and leave the rest alone: remove an object, fix a hand, change a sky, or add something that wasn’t there. Most Stable Diffusion inpainting guides still teach it with SD 1.5 in AUTOMATIC1111. Since then the model choice has changed. FLUX.1 Fill now does both inpainting and outpainting, and FLUX.1 Kontext edits images from a text instruction with no mask at all. This guide covers how inpainting works, which model to use and how much VRAM each needs, the settings that matter, and a ComfyUI workflow you can run locally.

Quick answer
- What it is: you give the model an image, a mask and a prompt. Hugging Face’s documentation puts the convention plainly: white pixels in the mask are regenerated from the prompt, and black pixels are kept. The prompt half is governed by the same 77-token budget as ordinary generation — see Stable Diffusion prompts, from the documentation.
- Best quality: FLUX.1 Fill [dev]. It’s a 12B model that needs a large card or heavy offloading, and its licence is non-commercial.
- Best on modest hardware: SDXL Inpainting 0.1. It works at 1024px and is small enough for a 12GB card at full precision.
- Lightest: SD 1.5 Inpainting, at 512px, runs on almost anything.
- No mask: FLUX.1 Kontext [dev] edits from a text instruction instead.
How inpainting works
Inpainting is image-to-image with a boundary. Hugging Face’s diffusers documentation describes the difference like this: image-to-image transforms the whole picture, while inpainting “only transforms the image area defined by the mask and the rest of the image is unchanged.”
You can inpaint with any ordinary checkpoint, but dedicated inpainting models do it better. The same is true at the other end of the workflow, where a dedicated upscale model beats a generic resize. The SD 1.5 inpainting model, for example, has “5 additional input channels (4 for the encoded masked-image and 1 for the mask itself)” and received 440,000 extra training steps on inpainting at 512×512. The model therefore sees the surrounding image while it generates, instead of only the noise it has to fill. For what a checkpoint actually contains, and why some ship a bundled VAE, see checkpoints, LoRAs and VAEs explained.
The diffusers documentation also describes the trade-off clearly:
- Regular checkpoints tend to leave the unmasked area alone, but the edit often shows a visible outline where the mask was.
- Inpainting checkpoints produce a cleaner, more natural transition. Because they blend across the boundary, though, they are “more likely to change your unmasked area.”
For simple jobs like erasing a small object, the documentation notes that a regular checkpoint “yields pretty good results”. Reach for a dedicated inpainting model when you’re adding or replacing something and the seam matters.
Which inpainting model to use
VRAM figures are estimates for batch 1 at each model’s native resolution. Each inpainting model shares the architecture and parameter count of its base model (FLUX.1 Fill [dev] is 11.90B parameters and SDXL Inpainting is 2.57B, per Hugging Face), so the figures reuse the base model’s computation from our image generation VRAM calculator. They are not measurements, so leave headroom.
| Model | Size | Resolution | VRAM, full precision | VRAM, lowest | Licence | Download |
|---|---|---|---|---|---|---|
| SD 1.5 Inpainting | SD 1.5 UNet | 512×512 | ~3.1 GB | ~1.5 GB | CreativeML OpenRAIL-M | Open |
| SDXL Inpainting 0.1 | 2.57B | 1024×1024 | ~9.2 GB | ~3.8 GB | OpenRAIL++ | Open |
| FLUX.1 Fill [dev] | 11.90B | 1024×1024 | ~36.5 GB | ~9.9 GB | FLUX.1 [dev] Non-Commercial | Gated (accept terms) |
| FLUX.1 Kontext [dev] | 11.90B | Instruction-based, no mask | Not estimated: the reference image adds memory our model doesn’t cover | FLUX.1 [dev] Non-Commercial | Gated (accept terms) | |
“Lowest” means 4-bit weights with the cheapest offload mode, which is much slower. At FP8, FLUX.1 Fill comes to about 19.8GB, which is why 24GB cards are the comfortable tier for it.
FLUX.1 Fill [dev]
Black Forest Labs released FLUX.1 Fill on 1 November 2024 as “inpainting and outpainting models, enabling editing and expansion of real and generated images given a text description and a binary mask”. There are open-weights [dev] and API-only [pro] versions. The model card lists two limitations worth knowing before you start: “slight color shifts in areas that are not filled in”, and possible “lines at the edges of the filled-area” on complex textures. Its diffusers example uses a guidance scale of 30 and 50 steps.
FLUX.1 Kontext [dev]
Kontext doesn’t use a mask. Its model card describes it as “capable of editing images based on text instructions”. You write something like “make the car red”, and the model decides what to change. That’s faster than drawing a mask, but it gives you less control over exactly which pixels move. When the boundary matters, use a masked model.
Added 26 September 2026: mask-free editing is no longer Kontext’s alone. Black Forest Labs’ FLUX.2 repository lists single-reference and multi-reference image editing as supported across the whole FLUX.2 line, including klein 4B — which, unlike every [dev] model here, is Apache-2.0 and fits roughly 8GB of VRAM by the repository’s own account. The FLUX.1 figures in the table above are unchanged, and our Flux LoRA licence guide works through which base models carry which restrictions. (Source: the FLUX.2 repository, read 26 September 2026.)
The settings that matter
- Denoise (called strength in diffusers). This sets how much noise goes into the masked area. According to the diffusers documentation, a high value makes the result more different from the original, and a low value keeps it closer. Use low values to fix details and high values to replace content.
- Mask feathering. A hard mask edge shows. ComfyUI’s VAE Encode (for Inpainting) node has
grow_mask_by, which “ensures a transition area around the mask to avoid hard edges”. Diffusers offers ablur_factorfor the same purpose. - Inpaint at higher resolution. A small masked area gets few pixels of attention. Diffusers’
padding_mask_cropcrops the masked region with some padding, upscales it for inpainting, and pastes the result back. - Protecting the rest of the image. If the unmasked area must stay exactly as it was, diffusers’
apply_overlay()pastes the original pixels back outside the mask. The trade-off is a less natural seam.
A local inpainting workflow in ComfyUI
If ComfyUI isn’t installed yet, start with our guide to running Stable Diffusion locally.
Basic workflow (SD 1.5 or SDXL inpainting checkpoint)
This follows ComfyUI’s own inpainting tutorial:
- Load Checkpoint: choose an inpainting checkpoint.
- Load Image: load your picture, then right-click the node and choose Open in MaskEditor. Paint over the area to regenerate, adjust the brush in the right-hand panel, and click Save.
- VAE Encode (for Inpainting): connect the image, the VAE and the mask, and set
grow_mask_byto soften the edge. - KSampler: write a prompt describing what should appear in the masked area, then run it.
- Save Image: the output keeps the unmasked area and fills the rest.
FLUX.1 Fill [dev] in ComfyUI
FLUX ships as separate files. ComfyUI’s FLUX.1 Fill tutorial lists four:
| File | Folder | Loaded by |
|---|---|---|
flux1-fill-dev.safetensors |
models/diffusion_models/ |
Load Diffusion Model |
t5xxl_fp16.safetensors |
models/text_encoders/ |
DualCLIPLoader (clip_name1) |
clip_l.safetensors |
models/text_encoders/ |
DualCLIPLoader (clip_name2) |
ae.safetensors |
models/vae/ |
Load VAE |
The same model and node setup handles outpainting: extending an image past its borders. Run the workflow with Queue or Ctrl/Cmd + Enter. If it doesn’t fit, FP8 weights and offloading the text encoder are the two main levers; our ComfyUI VRAM requirements page shows what each precision and offload mode saves. Video models push those limits harder still — see local AI video generation in ComfyUI.
Licences
- FLUX.1 Fill [dev] and FLUX.1 Kontext [dev] are both under the FLUX.1 [dev] Non-Commercial License. Don’t use their output in a product without a commercial agreement. FLUX dev vs schnell explains the licence split.
- SDXL Inpainting 0.1 uses OpenRAIL++, and SD 1.5 Inpainting uses CreativeML OpenRAIL-M. Both allow commercial use, subject to their use-based restrictions.
The image models directory lists licences for the base models too.
FAQ
Can I inpaint with any Stable Diffusion checkpoint?
Yes, but results differ. A regular checkpoint preserves the unmasked area well and often leaves a visible edge. A dedicated inpainting checkpoint blends the edit better, and it may alter nearby pixels. For erasing small objects, a regular checkpoint is usually fine.
What’s the difference between inpainting and img2img?
Img2img regenerates the whole image using the original as a guide. Inpainting regenerates only the masked area and keeps everything else. Which application you do that in is a separate decision from which model does it, and we compare the editors in Stable Diffusion image editors in 2026.
How much VRAM do I need for inpainting?
About the same as generating with the base model: roughly 3GB for SD 1.5 and 9GB for SDXL at full precision, and about 20GB for FLUX.1 Fill at FP8. If you’re short, see how to increase VRAM for what helps on each kind of hardware.
What is outpainting?
Outpainting extends an image beyond its original borders, filling the new area to match. FLUX.1 Fill does both inpainting and outpainting.
Sources
- Hugging Face diffusers: Inpainting guide
- Model cards: SD 1.5 Inpainting, SDXL Inpainting 0.1, FLUX.1 Fill [dev], FLUX.1 Kontext [dev]
- Black Forest Labs: FLUX.1 Tools announcement
- ComfyUI documentation: Inpainting workflow, FLUX.1 Fill [dev]
Updated September 15, 2026. VRAM figures are estimates computed from model file sizes, not benchmark measurements.
Work out what your hardware can actually run
Free calculators and directories, sized from real model weights — before you download gigabytes or order a card:

