A ComfyUI workflow JSON is a text file describing nodes, their connections, and their settings. It contains no models and no images. That is why importing someone else’s NSFW workflow so often fails: it references custom nodes and checkpoint filenames you do not have, and you must install or remap each one before it will run.
What a workflow JSON actually contains
Open a workflow file in a text editor and you will find plain, readable JSON. There are no weights inside it and no pictures. What it stores is a description of a graph: a list of nodes, each with a type identifier and a position on the canvas, a list of links describing which output socket feeds which input socket, and the values currently set in each node’s widgets. That is genuinely all of it, which is why these files are tiny compared to the models they orchestrate.
Understanding this one fact resolves most of the confusion around sharing workflows. The file is a recipe, not a meal. It names ingredients by string, so a checkpoint loader stores the filename of a checkpoint rather than the checkpoint itself, and a LoRA loader stores a LoRA filename rather than the LoRA. When you import that file on a machine where those filenames do not exist, the graph loads perfectly well and then fails the moment it tries to resolve a name into an actual file on disk.
Two file shapes you will encounter
There are two common serialisations and people mix them up constantly. The full workflow format is what you save from the interface and what you should generally share, because it preserves node positions, groups, notes, and everything needed to reconstruct the canvas as the author saw it. The API format is a leaner representation intended for programmatic execution, which strips the visual layout. If you load an API format file expecting a tidy canvas, you may get something that runs but looks nothing like the screenshots that came with it.
Workflows embedded in images
ComfyUI can write the workflow into the metadata of a generated PNG, which is why dragging a shared image onto the canvas frequently reconstructs the entire graph. This is genuinely useful and also fragile. Any step that strips metadata destroys it, and most platforms strip metadata on upload, so an image reposted through a social site or a chat app will almost always arrive with nothing embedded. If someone tells you the workflow is in the image and dragging it does nothing, the metadata was stripped somewhere in transit and no amount of retrying will bring it back. Ask for the JSON.
Importing a workflow, and what happens underneath
Loading is straightforward: you either use the interface’s load function to open a JSON file, or you drag a JSON or a metadata bearing PNG onto the canvas. What happens next is the part worth understanding. ComfyUI reads each node entry and looks up its type against the node types currently registered, which means the core nodes plus every custom node package installed in your custom nodes directory. If a type is not registered, that node cannot be constructed, and you get a placeholder or an error listing what could not be found.
Only after the graph is built do file references get resolved. Loader nodes present dropdowns populated by scanning your models directories at startup, so a checkpoint name saved by the author appears in your copy of the workflow as a value the dropdown cannot offer. This ordering explains a confusing experience many people report: the workflow appears to load fine, and then it fails on execution. The graph structure was valid. The contents it points at were not.
Import failure, ranked by how often it happens
| What you see | Cause | Fix |
|---|---|---|
| Message naming node types that could not be found | Custom node packages not installed | Install the packages, then restart |
| Loads fine, fails on run naming a checkpoint or LoRA | Model filename not present on disk | Repoint the loader to a model you have |
| Dragging a PNG does nothing | Metadata stripped in transit | Ask for the JSON file |
| Nothing loads, file rejected outright | Truncated or non workflow JSON | Redownload the raw file |
| Nodes present but a widget value looks wrong | Node package version differs from author’s | Match versions or set the value manually |
| Graph loads but the canvas looks scrambled | API format rather than full workflow | Request the full workflow export |
| Runs, but output is nothing like the example | Different base model behind the same name | Verify the exact model file and its version |
| Out of memory partway through execution | Resolution or batch size beyond your VRAM | Lower resolution and batch, then retest |
Resolving missing custom nodes
This is the number one reason a downloaded NSFW workflow does not run, and it is a direct consequence of how the community builds. Almost every widely shared advanced workflow leans on custom node packages, because those packages are where the interesting capability lives: better upscaling, detail refinement, mask handling, prompt utilities, control adapters, and so on. The author had them installed and the export simply recorded their node types by name.
The supported way to resolve this is the ComfyUI Manager, a widely used community extension whose entire purpose is installing and updating custom node packages, including a function that looks at the currently loaded workflow and identifies which of its node types are not present in your installation. That is exactly the problem you have, and using it is far more reliable than trying to identify unfamiliar node names by hand. After installing anything, restart the application, because node registration happens at startup and a package installed into a running instance is not visible until it reloads.
When a node genuinely cannot be found
Occasionally a workflow references a package that has been renamed, abandoned, or removed. In that case, look at what the node was doing in the graph rather than at its name. Most custom nodes are conveniences around a task that core nodes or a maintained alternative can also perform, and substituting is often straightforward once you understand the intent. A node in the middle of a chain that takes a latent and returns a latent is doing something to a latent, and identifying what it was doing usually points at a replacement.
Do not install everything you are offered
There is a real temptation to bulk install large numbers of packages so that any workflow will run. Resist it. Custom nodes bring their own Python dependencies, and conflicting version requirements between packages are the single most common cause of an installation that used to start and now does not. Install what a workflow actually needs, restart, and confirm things still work. If a fresh package breaks startup, the most recent addition is the first suspect, and our guide to ComfyUI failing to start or generate covers unpicking that situation.
Resolving missing models and checkpoints
Once the nodes exist, the next barrier is files. A checkpoint loader stores a filename, so the fix is conceptually simple: click that node’s dropdown and select a model you actually have. Where this gets subtle is that not every model is a valid substitute, and choosing badly produces output that looks nothing like the example while producing no error at all, which is far more confusing than a clean failure.
Match the architecture before anything else
The most important compatibility rule is that a workflow built around one base architecture will not behave correctly if you swap in a checkpoint from a different one. A LoRA trained for one base will not apply meaningfully to another. Resolutions that a workflow assumes will be wrong. Even the sampler and step values the author chose may be tuned to characteristics your substitute does not share. If you are unsure what any of this means in practice, our explainer on what a checkpoint actually is is the right starting point, and it will also tell you what to download to fill a gap properly.
Get the directory structure right
Models must sit in the correct subdirectory of the models folder for the relevant loader to see them. Checkpoints, LoRAs, VAEs, upscale models, and control adapters each have their own location, and a file in the wrong folder is invisible even though it is plainly on your disk. This is such a frequent cause of a supposedly missing model that it is worth checking before redownloading anything. Our walkthrough of installing checkpoints correctly covers where each file type belongs.
Beware of identical names with different contents
Popular models get reuploaded, requantised, merged, and renamed constantly, so two files sharing a name can contain very different weights. If a workflow reproduces the structure but not the character of the author’s results, a near miss on the model is a likely explanation. Where the author names a specific version, get that specific version rather than the newest one, since newer is frequently different rather than better for a workflow tuned to a particular release.
LoRAs are the second most common mismatch
LoRA loaders store filenames just as checkpoint loaders do, and a missing LoRA sometimes fails silently or with a weight that does nothing, rather than raising an obvious error. Check every LoRA node in a workflow individually, confirm each file exists, and confirm each is intended for the base you are running. Strengths are also highly tuned by the original author, so treat their values as a starting point rather than a rule. Our roundup of LoRAs worth using is a reasonable source when you need a substitute.
Adapting a workflow to the setup you actually have
Work outward from the loaders
The reliable method for making a foreign workflow yours is to fix the graph in dependency order. First get every node registered so the graph is complete. Then repoint every loader at a real file. Then run once at a deliberately low resolution and a batch size of one, purely to prove the graph executes end to end. Only after a successful run should you touch anything creative. Changing prompts and samplers before you have a single successful execution means you can never tell whether a failure came from the workflow or from your edits.
Scale to your hardware, not to the author’s
Workflows are often built and shared by people running high memory cards, and the resolutions, batch sizes, and upscaling chains reflect that. If you have less VRAM, expect to reduce the working resolution, keep the batch size at one, and possibly disable an upscale or detail pass on the first run. Once the graph works, raise one setting at a time until you find your ceiling. This is far more informative than guessing, and our notes on running well on limited VRAM cover the model side of the same constraint.
Prune what you do not need
Shared workflows accumulate optional branches: alternative upscalers, disabled experiments, comparison outputs, notes to the author’s future self. Once you have a working run, deleting the branches you are not using makes the graph far easier to reason about and reduces the number of things that can break next time. Save your pruned version under a new name and keep the original, so you can always go back to the author’s arrangement.
Understand what each functional block does
The step that turns a copied workflow into a useful skill is recognising the recurring blocks. A detail refinement pass, a mask driven inpainting section, an upscale chain, and a pose or composition conditioning branch all look like a tangle of nodes until you have seen each one a few times, after which they read at a glance. Our guides to inpainting workflows and to upscaling inside ComfyUI explain two of the most common blocks in detail, and the broader ComfyUI guide for NSFW work puts the whole picture together.
Judging a workflow before you spend time on it
Not every shared file is worth the effort of getting running. Good indicators are a stated base architecture, named models with versions, an explicit list of required custom node packages, and example images that plausibly came from that graph. Poor indicators are a file with no description, results far beyond what the named model normally produces, and an unusually long list of exotic dependencies for a simple looking task. A workflow you cannot evaluate is a workflow you will be debugging blind, and debugging someone else’s blind is how an evening disappears.
Frequently asked questions
What is inside a ComfyUI workflow JSON file?
Plain text describing a graph: every node with its type and canvas position, every link between output and input sockets, and the widget values set on each node. It contains no model weights and no images, which is why the files are small. Models, LoRAs, and other assets are referenced only by filename, so the same file behaves very differently on a machine that lacks those files.
Why does my downloaded workflow say nodes are missing?
Because it uses custom node packages that are not installed on your machine. Node types are registered at startup from the core set plus whatever sits in your custom nodes directory, so any type the author had and you do not cannot be constructed. Use the ComfyUI Manager to identify and install what the loaded workflow requires, then restart, since registration only happens when the application starts.
Can I run an NSFW workflow without the exact checkpoint it names?
Usually yes, provided your substitute is built on the same base architecture. Repoint the checkpoint loader at a model you have and run it. Expect the output to differ in style and character even when it works, because prompts, samplers, steps, and LoRA strengths in a shared workflow are tuned to a specific model. Swapping across different architectures generally produces poor results rather than a clean error.
Why does dragging the example image onto the canvas do nothing?
The embedded workflow metadata was stripped somewhere between the author and you. Most social platforms, chat apps, and image hosts strip metadata on upload, and any conversion or re export removes it too. The image itself is undamaged, but the workflow that was attached to it is gone and cannot be recovered from the pixels. Ask the author for the JSON file directly instead.
Should I install every custom node package a workflow suggests?
Install what that workflow needs and nothing more. Custom node packages bring Python dependencies, and conflicting requirements between packages are the most common reason a working installation stops starting. Add packages in small groups, restart, and confirm things still run before adding more. If startup breaks, the package you added most recently is the first thing to remove while you diagnose.
The workflow runs but my images look nothing like the examples. Why?
Almost always a model mismatch. Either you substituted a checkpoint from a different family, or you have a file that shares a name with the author’s but contains different weights after a reupload or a merge. Missing LoRAs are the next suspect, since they sometimes fail quietly rather than raising an error. Verify each loader individually against exactly what the author specified before adjusting prompts.
How do I make a heavy workflow fit a smaller graphics card?
Reduce the working resolution first, keep the batch size at one, and temporarily disable any upscale or detail refinement pass so you can confirm the core graph executes. Once it runs cleanly, raise one setting at a time until you hit an out of memory error, then step back. Working upward from a known good baseline is far more informative than guessing at settings that might fit.
What is the difference between the workflow and API JSON formats?
The workflow format is the full export from the interface and preserves node positions, groups, notes, and the layout as the author arranged it, so it is the right thing to share. The API format is a leaner description meant for programmatic execution and drops the visual arrangement. Both can describe the same graph, but loading an API export gives you something that runs without looking like the original canvas.
