Nodes/SD Prompt Reader/SD Prompt Merger
ComfyUI Node

SD Prompt Merger

SDXL's text_g and text_l in one string — because A1111 metadata can't hold both

By receyuki·Created 3 years ago·Updated 2 years ago· 463
SD Prompt Merger
    • STRING
    text_g
    text_l

    SDPromptMerger is the smallest node in the SD Prompt Reader pack, and it exists because of a format mismatch nobody designed on purpose. SDXL's CLIP runs two text encoders, which means ComfyUI gives you two prompt inputs - text_g for the big model, text_l for the smaller one. But the A1111 metadata format stores exactly one prompt per image. So when you want an SDXL workflow's output to be readable by Civitai and prompt-reader tools, those two strings have to become one. That's all this node does: it takes text_g and text_l and returns a single combined string.

    How it works

    Two inputs, both optional, both multiline strings: text_g and text_l. The output is a single STRING. The merge rule is simple and predictable: if both are non-empty, you get text_g, a newline, then text_l; if only one is filled in, you get that one unchanged. No weighting, no token juggling, no clever recombination - just a concatenation with a line break between the halves.

    That simplicity is the point. The typical wiring in an SDXL workflow is: put this node between your two CLIP Text Encode nodes and the SD Prompt Saver. The saver gets one combined prompt to write into the A1111-format metadata, instead of having to guess which of two strings is "the" prompt. If you've ever looked at an SDXL image's metadata and seen only half the prompt - usually just text_g - this is the node that was missing.

    The catch: which half goes first

    It matters that text_g comes first. The SDXL convention is that text_g is the primary, higher-weight prompt and text_l is the secondary support. When the reader on the other end combines them back, it expects that order. Wire text_g (the CLIP Text Encode output you consider the main prompt) into text_g, not into text_l, or your metadata will read as a weirdly reversed prompt to anyone who inspects it. The node itself won't stop you - it's just a string op.

    Do you even need it?

    Only if you care about round-tripping SDXL prompts through A1111-style metadata. If you're doing pure ComfyUI-to-ComfyUI sharing, you don't need this at all - the embedded workflow JSON already captures both prompts perfectly, and the pack's SD Prompt Reader even auto-combines text_g and text_l when it reads them back. The merger only earns its slot when your SDXL output has to play nice with tools that speak one-prompt A1111 - Civitai uploads being the big one.

    The pack's README pairs this node with a Type Converter node, which handles a related annoyance: model_name, sampler_name, and scheduler come out of some nodes as special types that other nodes refuse to accept as plain text. If you hit that, the Type Converter is the sibling to reach for.

    Installing it

    It ships in the SD Prompt Reader pack, so the install is identical to the rest of the pack:

    cd ComfyUI/custom_nodes
    git clone --recursive https://github.com/receyuki/comfyui-prompt-reader-node.git
    cd comfyui-prompt-reader-node
    pip install -r requirements.txt
    

    Or search "SD Prompt Reader" in ComfyUI Manager. Restart after. There's genuinely nothing else to configure - no models, no settings, the pack's only dependency is piexif and this node barely touches it.

    CategorySD Prompt Reader

    Inputs (2)

    NameTypeDefaultDescription
    text_goptSTRING
    text_loptSTRING

    Outputs (1)

    NameTypeDescription
    STRINGSTRING