ComfyUI Node

ZFL JSON Extractor

Turn one LLM JSON script into four clean ComfyUI strings

By xufengbo1993·Created 7 months ago·Updated 7 months ago· 0
ZFL JSON Extractor
    • output_1
    • output_2
    • output_3
    • output_4
    json_string
    key_1name
    key_2instruct
    key_3text
    key_4other
    delimiter

    So you asked an LLM to write you a script - a comic, an animation, a voiceover - and it came back as JSON: an array of scene objects, each with a name, an instruct, a text, maybe an other. Now you need that JSON turned into actual strings ComfyUI can use: the character names for a consistency LoRA workflow, the instructions for TTS, the dialogue for captioning. That's the whole job of the ZFL JSON Extractor. It's the boring middle step between "LLM produced structured output" and "image generator actually reads it," and it does it in one node.

    Structured prompts are a real thing in 2026 - for LLM-encoded models, JSON with cleanly separated fields reads as a clear instruction to the text encoder, and the community has had good results holding composition together with a composition field. The catch is that ComfyUI doesn't ship a native "split this JSON dict" node. That's where this one slots in.

    How it works

    The mechanism is dead simple - the whole pack is one ~60-line __init__.py with no dependencies beyond Python's built-in json module. Feed it a JSON string, it parses it, and for each object in the array it pulls up to four keys and joins each key's values into a separate multi-line string.

    Under the hood: if the parsed JSON isn't already a list, it wraps it in one. Then it walks each item and, for each of your four keys, appends str(value) to that key's output list. Keys that are missing in a given scene are just skipped. Finally each list is joined with your delimiter (default \n) and handed out as four STRING outputs. Nothing to download, nothing heavy - a text node, not a model node.

    The inputs that matter

    Six inputs, all plain strings, and only three you'll actually fiddle with:

    • json_string (multiline) - paste the LLM output here, or wire in a node that returns one.
    • key_1..key_4 - the JSON keys to pull, defaulting to name, instruct, text, other. If your script calls them character and dialogue, type those in.
    • delimiter - what separates the collected lines. \n gives you one value per line; | or a tab is handy if a downstream node wants a single-line string.

    The four outputs (output_1..output_4) are plain strings - wire them into anything that takes a STRING: a text encoder, a TTS node, a save-text node, whatever.

    Installation

    This is the easy kind of install. ComfyUI Manager: search for ComfyUI-ZFL-JSON-Extractor and hit install. Or by hand:

    cd ComfyUI/custom_nodes
    git clone https://github.com/xufengbo1993/ComfyUI-ZFL-JSON-Extractor
    

    Restart ComfyUI. There's no requirements.txt and no model download, so nothing to break and nothing to conflict with - after the custom-node dependency horror stories, a pure-stdlib pack is genuinely refreshing. Since it's this small, glance at the __init__.py yourself before trusting it; with any custom node, reading the source is the only real security check.

    Where it bites

    The README's headline feature, the "auto-fix" for single-quote JSON, is the thing to watch. It's literally json_string.replace("'", '"') - every single quote, no judgment. That fixes LLM output that wraps keys and values in single quotes, but it also rewrites apostrophes inside your dialogue: "It's fine" becomes "It"s fine", which is now invalid JSON and the parse fails. Dialogue-heavy scripts with contractions are exactly where this bites. The actual fix is to make the LLM emit strict JSON from the start, not to rely on this.

    Two more quirks worth knowing. The keys are top-level only - no scene.character nested paths. And if a scene is missing a key, its entry is skipped, so your four outputs can end up with different line counts and the rows stop lining up across outputs. Finally, on any parse error it doesn't red-light the node - it quietly returns "Error: ..." in output_1 and empties the rest, so a bad string can flow downstream looking like data. If a workflow starts producing garbage, check output_1 for an Error: prefix first. For a script-splitting chore you'd otherwise do by hand, it's still the fastest option on the menu.

    CategoryCustomNodes/TextProcessing

    Inputs (6)

    NameTypeDefaultDescription
    json_stringSTRING
    key_1STRINGname
    key_2STRINGinstruct
    key_3STRINGtext
    key_4STRINGother
    delimiterSTRING

    Outputs (4)

    NameTypeDescription
    output_1STRING
    output_2STRING
    output_3STRING
    output_4STRING