SDXL Prompt Handling Plus (JPS)

SDXL's real text-conditioning node wants two separate prompt strings - text_g for its larger OpenCLIP-bigG encoder (does most of the heavy lifting on composition and detail) and text_l for the smaller CLIP-L encoder. Most people don't want to hand-write two different prompts every time, and that gap between "SDXL technically wants two inputs" and "I have one prompt" is exactly what this node exists to close.

How it works

handling is the whole mechanism - an eight-way dropdown that decides what happens to pos_g and pos_l before they get passed on. The forgiving default is "Copy to Both if Empty": write into either box (or both), and whichever one you left blank gets filled from the other automatically. Prefer to always use one and ignore the other entirely? "Copy Positive_G to Both" / "Copy Positive_L to Both" does that regardless of what's typed in the ignored box. "Use Positive_G + Positive_L" keeps the two genuinely separate, for when you actually want to tune composition-level phrasing differently from close-in subject detail. "Ignore Positive_G Input" / "Ignore Positive_L Input" force one input to always win, full stop - useful for locking a workflow's behavior regardless of what a user fills in. And "Combine Positive_G + Positive_L" / "Combine Positive_L + Positive_G" concatenate both boxes into one string, fed to both outputs, in the stated order.

This node only produces strings - it does the text logic, not the actual CLIP encoding. You still need a CLIPTextEncodeSDXL (or your loader's equivalent) downstream to turn pos_g/pos_l into real conditioning.

The inputs and outputs that matter

• handling (enum, 8 choices) - the behavior described above.
• pos_g, pos_l (STRING, multiline, required) - your prompt text.
• Outputs: pos_g, pos_l (STRING) - feed straight into CLIPTextEncodeSDXL's text_g and text_l inputs.

Beginner path: set handling to "Copy to Both if Empty," write one prompt into pos_g, leave pos_l blank. You get SDXL's dual-encoder behavior without thinking about it further. Only reach for "Combine" or the separate-input mode once you've actually noticed tuning G and L differently makes a difference - the common report is composition-heavy phrasing landing better in G, closer subject detail in L.

How to install it

ComfyUI Manager: search "JPS Custom Nodes for ComfyUI." Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/JPS-GER/ComfyUI_JPS-Nodes.git

Restart. No models, no extra dependencies - this is a string-logic node.

Common issues & troubleshooting

Part of your prompt seems ignored. Check handling first. "Ignore Positive_L Input" will silently drop whatever's in pos_l no matter what you type there - it reads exactly like a bug the first time you hit it, but it's the setting working as configured.

Nothing happens after this node. It only outputs text strings, not conditioning. If your prompt "isn't doing anything," confirm you've actually got a CLIPTextEncodeSDXL (or equivalent) downstream consuming pos_g/pos_l - this node's job ends at producing the two strings.

Not sure whether G/L separation is worth the effort. For most day-to-day generation it isn't - "Copy to Both if Empty" with a single prompt covers the vast majority of use cases well. Genuine G/L separation is a fine-tuning move for when you're chasing a specific composition-versus-detail balance, not a default habit to build.