A black image in Stable Diffusion comes from one of two things: the built-in NSFW safety checker swapping your result for a black frame, or a NaN math error (usually fp16 VAE on certain GPUs). Disable the safety checker, or add –no-half-vae, and the black image is gone.
You typed a prompt, hit generate, and got back a solid black square. Maybe a console line read “Potential NSFW content was detected in one or more images. A black image will be returned instead.” Maybe there was no message at all, just black. This is one of the most common and most confusing problems in local Stable Diffusion, because two completely different causes produce the exact same black-image symptom. One is a deliberate content filter. The other is a floating-point math crash. This guide covers every fix for both, with a decision flow so you know which one is biting you.
Want to try now? Use our free AI generator at aiimagegeneratornsfw.com/#generator, no login, no black-image filter, no install. Generate uncensored results in your browser in seconds while you sort out your local setup.
The two causes of a black image (and how to tell them apart)
Before you change a single setting, identify which problem you have. Guessing wastes hours because the fixes are opposite in nature. One is a software toggle, the other is a precision flag.
Cause A – the NSFW safety checker. This is a real classifier model that scores every generated image and, if the score crosses a threshold, replaces the image with a black frame. It triggers on adult, suggestive, or even some borderline non-adult content. The tell: it usually prints a message containing the words “NSFW content was detected” and the black image is consistent and reproducible for the same seed and prompt. SFW prompts come back fine.
Cause B – the NaN / fp16 math error. Here the latent or VAE decode produces NaN (not-a-number) values, and the decoded pixels collapse to black. The tell: it happens regardless of prompt content, often with a console warning about NaNs, and it correlates with specific GPUs (older Nvidia 16-series cards like the GTX 1650/1660 are notorious) or specific VAE files. SFW and NSFW prompts both go black.
| Symptom | Cause A: Safety checker | Cause B: NaN / fp16 |
|---|---|---|
| Console message | “NSFW content was detected” | “A tensor with all NaNs was produced” or silent |
| SFW prompts | Work fine | Also go black |
| GPU correlation | None | GTX 16-series, some older cards |
| Reproducible by seed | Yes, consistent | Often intermittent |
| Fix type | Disable filter | Precision flag (–no-half-vae) |
Fix for AUTOMATIC1111 (the most common UI)
Here is the good news that surprises a lot of people: AUTOMATIC1111 stable-diffusion-webui ships with the NSFW safety checker disabled by default. The base install does not censor your generations. So if you are getting a black image in a stock A1111 install, your problem is almost certainly Cause B, not the filter.
The rare exception: you (or a tutorial you followed) installed an extension that re-adds a safety checker, or you are running a fork that bundled one. Go to the Extensions tab, look for anything named like “NSFW censor”, “safety checker”, or “stable-diffusion-webui-nsfw-censor”, and disable it. Then fully restart the UI, not just reload.
If SFW images also come back black in A1111, you have the NaN bug. Edit your launch file (webui-user.bat on Windows, webui-user.sh on Linux) and add command-line arguments to the COMMANDLINE_ARGS line:
--no-half-vae– keeps the VAE in full precision. This fixes the overwhelming majority of black-image NaN cases and costs very little VRAM.--no-half– forces full precision everywhere. Heavier on VRAM, but a guaranteed fix when –no-half-vae alone is not enough.--upcast-sampling– a lighter-weight option for newer cards that often resolves NaNs without the full –no-half penalty.--disable-nan-check– this does NOT fix the black image, it only stops the crash message. Do not rely on it as a fix.
A typical fixed line looks like: set COMMANDLINE_ARGS=--no-half-vae --upcast-sampling. Save, close, and relaunch.
The fp16 VAE fix (the single most common real cause)
Most SDXL and many SD 1.5 black-image reports trace back to one thing: the fp16 (half precision) VAE producing NaNs during decode. SDXL’s original VAE is mathematically unstable in fp16 on a lot of hardware. There are three ways to solve it permanently.
- Use the fixed fp16 VAE. Download the community “sdxl-vae-fp16-fix” from Hugging Face and select it in Settings > VAE. It is built specifically to be numerically stable in half precision.
- Force the VAE to full precision with –no-half-vae as above. Simple and reliable.
- Bake the VAE into the checkpoint. Many modern checkpoints from Civitai already include a stable VAE, so switching to a well-maintained NSFW checkpoint can make the problem disappear entirely.
If you want a deeper dive on choosing the right base model, our guide to the best Stable Diffusion checkpoints for NSFW walks through which checkpoints ship with stable VAEs.
Fix for the diffusers library (Python code)
If you are running Stable Diffusion through the Hugging Face diffusers library in your own Python script, the safety checker IS on by default for many pipelines. This is the classic source of “A black image will be returned instead.” Disable it when you load the pipeline:
from diffusers import StableDiffusionPipeline
import torch
pipe = StableDiffusionPipeline.from_pretrained(
"runwayml/stable-diffusion-v1-5",
safety_checker=None,
requires_safety_checker=False,
torch_dtype=torch.float16,
).to("cuda")
# If you still get black images on an older GPU, drop to float32 for the VAE:
pipe.vae = pipe.vae.to(dtype=torch.float32)
image = pipe("your prompt here").images[0]
image.save("out.png")The two arguments that matter are safety_checker=None and requires_safety_checker=False. Setting only one of them can still trigger warnings or a fallback. Set both. For SDXL pipelines (StableDiffusionXLPipeline) there is no safety_checker argument at all because SDXL’s diffusers pipeline does not bundle one, so an SDXL black image in diffusers is always the NaN issue, fixed by loading the fp16-fix VAE or casting the VAE to float32.
Fix for ComfyUI
ComfyUI does not include an NSFW safety checker in its core install. There is no node in the default workflow that censors output, so a black image in ComfyUI is essentially never the filter. It is the NaN / VAE problem. Fixes:
- Launch ComfyUI with
--fp32-vae(or--force-fp32for everything) to keep the VAE decode in full precision. - Load a dedicated stable VAE via a “Load VAE” node and feed it to the VAEDecode node instead of relying on the checkpoint’s baked VAE.
- Add the
--dont-upcast-attentionflag only if a custom node introduced an instability; usually you want the default upcasting. - Check custom nodes. A rogue community node (rare, but it happens) can re-introduce a content classifier. Disable suspicious nodes one at a time.
Our full ComfyUI for NSFW guide shows a clean uncensored workflow from scratch if you want to rebuild rather than debug.
Fix for Forge and other forks
Stable Diffusion WebUI Forge inherits A1111’s behavior: no safety checker by default. Forge also handles VRAM and precision differently, which means its memory management sometimes sidesteps the NaN issue automatically, and other times you still need –no-half-vae in its argument list. Add the same flags to Forge’s launch arguments. Our Forge NSFW setup guide covers the full clean install including the precision flags.
Rogue extensions and the “it came back” problem
If your black image suddenly returns after weeks of working, the most likely cause is an extension or checkpoint update. Some “all-in-one” installer scripts and some content-moderation extensions silently add a safety checker back. The diagnostic: disable every extension, restart, and test. If the black image is gone, re-enable extensions one at a time until it returns. The last one you enabled is the culprit. Common offenders are anything with “censor”, “moderation”, or “safe” in the name.
Another sneaky source: a workflow or preset JSON you imported that flips a setting. Reset to defaults if you cannot find the toggle. And if you are on a hosted/cloud instance (RunPod, Vast, a Colab notebook), the host may enforce a filter at the platform level that you cannot disable. In that case the only real fix is a different host or a local install.
The decision flow: which fix is yours?
- Do SFW prompts also go black? If yes, it is the NaN bug. Add –no-half-vae (A1111/Forge) or –fp32-vae (ComfyUI), or load the fp16-fix VAE. If no, it is a content filter.
- Are you using the diffusers library directly? Set safety_checker=None and requires_safety_checker=False.
- Are you on a GTX 16-series or older GPU? Strongly suspect NaN. Try –no-half-vae first, then –no-half.
- Did it work before and just broke? A recent extension or installer re-added a censor. Disable extensions and bisect.
- On a cloud host? Check whether the platform enforces moderation you cannot override.
Follow that chain in order and you will land on the right fix without trial-and-error. Once your VAE is stable and any stray filter is off, dial in your generation quality with our CFG and sampler settings guide and a solid set of negative prompts that actually work.
Step-by-step: the fastest permanent fix
If you just want a recipe that resolves the majority of cases in one pass, do this in order. It targets the fp16 VAE NaN problem first, because that is statistically the most common real cause in modern SDXL workflows, then mops up any filter that might be present.
- Close the WebUI completely. A reload from the browser does not re-read launch arguments, so a full process restart is required for any flag change to take effect.
- Open webui-user.bat (Windows) or webui-user.sh (Linux/Mac) in a plain text editor.
- Set the arguments line to
set COMMANDLINE_ARGS=--no-half-vae --upcast-samplingon Windows, or the sh equivalent without the word “set”. - Save and relaunch. Generate a known-good SFW prompt at the same seed that produced black. If it now renders, the NaN bug was your problem and you are done.
- If it is still black, escalate to
--no-halfin place of –upcast-sampling. This is heavier on VRAM but the most reliable NaN cure. - If SFW now works but explicit prompts are still black, you have a filter. In the diffusers library set safety_checker=None; in a UI, hunt for and disable any censor extension.
- As a belt-and-braces step, download the sdxl-vae-fp16-fix VAE and select it in Settings > VAE, then click Apply. This makes half precision stable even without the launch flag.
Ninety percent of users are done after step 4. The remaining steps cover the stubborn hardware cases and the genuine filter cases.
Common mistakes that keep the black image coming back
Even after applying the right flag, people stay stuck because of small process errors. Watch for these:
- Editing the wrong file. Arguments must go in webui-user.bat, not webui.bat or the .py launcher. Many guides confuse these and the edit silently does nothing.
- Adding flags to a quotes-broken line. A missing or extra quote turns your whole argument string into garbage that the launcher ignores. Keep it as one clean line.
- Relying on –disable-nan-check as a fix. It only hides the crash. The image is still mathematically NaN and still black. Use a real precision flag.
- Forgetting to switch the VAE in the UI. If you download the fp16-fix VAE but never select it under Settings, nothing changes.
- A cached or stuck VAE. After changing VAE settings, generate a fresh image rather than re-running the same job, which may reuse a cached bad decode.
- Mixing model and VAE precision. On older cards, a half-precision model with a half-precision VAE compounds instability. –no-half-vae alone often fixes it without the full –no-half hit.
If you have worked through the decision flow, applied the launch flag, swapped to a stable VAE, and disabled extensions and the black square persists only on certain checkpoints, the checkpoint itself may have a corrupt or merged-bad VAE. Switch to a well-maintained model and the problem usually vanishes, which loops back to choosing a solid base model from the start.
Why the safety checker exists and why disabling it is fine for local use
It helps to understand what you are turning off. The safety_checker is a small CLIP-based classifier that the original Stable Diffusion researchers bundled to discourage casual generation of explicit content in public demos and hosted apps. It compares the generated image’s embedding against a set of reference concepts and, if the similarity crosses a threshold, flags the image and returns a black frame. It was never a security feature and it never deletes anything; it simply blanks the output.
Two things are worth knowing. First, it is imprecise: it produces frequent false positives, blanking innocent images like a person in a swimsuit or even abstract art, which is part of why so many users disable it. Second, on a private local install for a consenting adult, there is no policy reason it needs to run, which is exactly why AUTOMATIC1111 ships with it off. Disabling it is the normal, intended configuration for local NSFW work. Your responsibility is unchanged: only generate legal content involving adults. The filter being off does not alter the law, it just stops the false-positive black frames.
When none of the fixes work: deeper diagnostics
A small number of cases survive every standard fix. Here is how to dig deeper before giving up:
- Read the actual console output. The terminal window behind the UI usually states the real error: a NaN warning, an out-of-memory event that silently produced black, or a safety message. The fix follows directly from which one appears.
- Test a different VAE in isolation. Load a known-good standalone VAE and decode the same latent. If it renders, your previous VAE was the culprit.
- Lower the resolution. An out-of-memory condition can produce black or partial output. Drop to 512×512 (SD 1.5) or 1024×1024 (SDXL) to rule out VRAM exhaustion.
- Update your GPU drivers and torch. Old CUDA or torch builds carry known NaN bugs on certain cards that newer versions fix outright.
- Try a clean install in a fresh folder. A corrupted venv or a half-applied update can poison an install. A clean clone with default settings isolates whether the problem is your config or your hardware.
Between the precision flags, the VAE swap, the filter check, and these deeper diagnostics, there is no black-image scenario in Stable Diffusion that does not have a concrete fix. The hard part was only ever knowing which of the two root causes you were facing, and the decision flow above settles that in under a minute.
Related guides
- Best Stable Diffusion checkpoints for NSFW 2026
- ComfyUI for NSFW: complete guide
- Stable Diffusion Forge NSFW setup guide
- Best local NSFW AI image generator 2026
Frequently Asked Questions
Why does Stable Diffusion give me an all-black image?
Two causes produce the same black square. Either the built-in NSFW safety checker replaced your image with a black frame, or a NaN math error (usually the fp16 VAE on older GPUs) collapsed the decode to black. If SFW prompts also go black, it is the NaN bug, not the filter.
What does ‘Potential NSFW content was detected, a black image will be returned’ mean?
That message comes from the safety_checker classifier, which scores each image and swaps it for a black frame when it crosses a threshold. It is most common in the diffusers library. Disable it with safety_checker=None and requires_safety_checker=False when loading the pipeline.
Does AUTOMATIC1111 censor NSFW images by default?
No. A stock AUTOMATIC1111 stable-diffusion-webui install ships with the safety checker disabled. If you get black images there, it is almost always the NaN/fp16 VAE bug, not a filter. The rare exception is a censor extension you or a tutorial installed.
How do I fix the fp16 VAE black image bug?
Add –no-half-vae to your A1111/Forge launch arguments, use –fp32-vae in ComfyUI, or download the community sdxl-vae-fp16-fix VAE from Hugging Face and select it in settings. Any one of these keeps the VAE decode numerically stable and stops the black output.
Why do SFW prompts also come back black?
That points to the NaN / floating-point error rather than a content filter. The latent or VAE decode produced not-a-number values, so the pixels collapsed to black. This correlates with GTX 16-series and older GPUs. Fix it with –no-half-vae or –no-half.
Does ComfyUI have an NSFW filter?
No, ComfyUI’s core install has no safety checker, so a black image there is the NaN/VAE issue, not censorship. Launch with –fp32-vae or load a dedicated stable VAE node. If a custom node reintroduced a classifier, disable suspect nodes one at a time.
My images worked before and now they are black again. Why?
A recent extension update or installer script most likely re-added a safety checker, or a checkpoint update changed your VAE. Disable all extensions, restart, and re-enable them one at a time until the black image returns to identify the culprit.
Is there a way to generate uncensored images without fixing all this?
Yes. Our free generator at aiimagegeneratornsfw.com/#generator runs uncensored in your browser with no install, no login, and no black-image filter. It is the fastest way to keep generating while you debug your local Stable Diffusion setup.
