Convert JSON to YAML

JSON is what your workflow speaks internally. YAML is what a lot of the outside world wants - config files, some LLM prompts read far better as YAML, and a fair number of APIs and tools accept either. Convert JSON to YAML is the one-way bridge between the two, and it has one thoughtful detail that makes it genuinely nicer than a generic json.loads + yaml.dump.

How it works

The node parses the input with json.loads (strict - it must be valid JSON), then re-emits it via a custom YAML dumper built on yaml.SafeDumper. It writes with 4-space indentation, Unicode-friendly (allow_unicode), and sorts keys if you ask. The clever bit is multiline_string_enabled, default on: any string containing a newline is rendered as a YAML literal block scalar (|) with trailing whitespace trimmed. That keeps long multi-line prompts, prompts-with-newlines, or embedded text readable in the output instead of turning into a wall of \n escapes. Disable it and you get the escape-heavy representation.

The dumper class is created fresh per execution specifically to avoid global state pollution between runs - a small correctness detail that says someone thought about the dirty corners of shared YAML representers.

Inputs and outputs

• input_string - the JSON, multiline.
• pretty_enabled - default on; controls indentation of the emitted YAML.
• multiline_string_enabled - default on; the literal-block behavior above.
• sort_enabled - default off; alphabetizes keys.

The output is Output YAML String. Invalid JSON is caught and returned as a JSON {"error": "..."} object rather than killing your run.

Why you'd reach for it

A workflow that talks to an external tool that consumes YAML config, an LLM node that responds better to indentation than to brace soup, or just wanting to eyeball a JSON blob in a format your brain parses faster. Pair it with the pack's DisplayStringData to actually look at the result - this node alone is an output node but its output is a raw string, and the display node makes it readable.

Install

ComfyUI Manager → search "comfy-nekonote-extensions", or:

cd ComfyUI/custom_nodes
git clone https://github.com/0nyx-networks/comfy-nekonote-extensions

Restart, and it's under NEKONOTE → Text. Part of the small MIT-licensed comfy-nekonote-extensions utility pack by MINETA "m10i" Hiroki (v0.4.7) - no models, no GPU, and its dependencies (pyyaml being the relevant one here) are already in almost every ComfyUI environment. Note this pack targets the newer comfy_api.latest backend API, so if nodes never appear, update ComfyUI first.