JSON Stringifier

Once you've built or modified JSON somewhere in your graph - through JSONGeneratorNode, JSONMergeNode, JSONModifierNode, whatever - you eventually need it formatted for wherever it's going next: readable for a debug display, or compact for an API call. JSON Stringifier is the formatting step. It doesn't change the data, only how it's laid out as text.

How it works

It's json.dumps() with the two options people actually reach for exposed as node inputs: indentation width and whether keys get alphabetized. Everything else about the JSON - the actual keys and values - passes through unchanged.

The inputs and outputs that matter

• json_input - multiline string, whatever JSON you want reformatted.
• indent - INT, default 2, range 0–8. This controls how many spaces of indentation each nesting level gets. 0 gives you the most compact form - no line breaks between elements - which is what you want feeding into an API call where every byte counts and readability doesn't matter. Higher values (the default of 2, or up to 8) spread it out for a human reading it in a debug panel.
• sort_keys - BOOLEAN, default false. Flip it on if you want a deterministic, alphabetized key order - useful for diffing two JSON outputs against each other, or just for consistency when you're eyeballing output across multiple runs.
• json_string (output) - the formatted result, as a STRING.

That's the entire surface: one thing you're formatting, two knobs for how it looks coming out.

How to install it

Search ComfyUI Manager for "Simple JSON Parser" or "Json Node"; if that comes up empty, install directly:

cd ComfyUI/custom_nodes
git clone https://github.com/Q-Bug4/Comfyui-Simple-Json-Node

Restart ComfyUI. No dependencies, no model downloads - this pack is pure string/dict manipulation from top to bottom, so the install is trivial regardless of which node in it you're after.

Common issues & troubleshooting

Why does the output look identical to the input? If your json_input is already a plain string that happens to look like JSON, and you feed it straight to this node without it having gone through an actual parse-modify-generate step first, you might just be seeing the same formatting choices reflected back. This node reformats structured JSON; it's not a general-purpose beautifier for arbitrary text that merely resembles JSON. If the input string itself is malformed, expect the same ValueError behavior the rest of the pack documents for invalid JSON - this node doesn't silently pass through broken input either.

Debugging a workflow and the JSON is unreadable in the console/output panel. This is the actual day-to-day use case for this node even outside any "final output" scenario - drop a JSONStringifierNode with indent=4 or so mid-graph, right after whatever step you're suspicious of, and read the formatted output rather than squinting at a single-line blob. Cheap to add, cheap to remove once you've found the bug.

Sending to an API and it's rejecting the payload over whitespace. Some strict API consumers care about exact formatting. If you're building a request body with JSONGeneratorNode or JSONMergeNode and something downstream is rejecting it, try indent=0 here as the last formatting step before it leaves your graph - compact JSON with no indentation is the safest default for anything that isn't meant to be read by a human.

sort_keys changing behavior you didn't expect. If a downstream consumer cares about key order specifically (rare, but some hand-rolled parsers do), leave sort_keys off - it defaults to false for a reason. It's there for readability and diffing, not because most JSON consumers require or even notice alphabetized keys.