String Literal (Image Saver)

A multiline text box that outputs its contents as a string. Trivial on the surface, and genuinely handy in the Image Saver pack's world: your prompt needs to reach both the CLIP text encoder (to actually condition the image) and the saver's positive / negative fields (to be recorded in the metadata). Type it into String Literal once and wire it to both, and the prompt saved in your image is guaranteed to be the prompt that generated it - not a slightly-edited copy you forgot to sync.

How it works

You type text into the multiline field; it comes out as a STRING. No parsing, no templating - it's a shared text source. Connect the output to a CLIP Text Encode node and to your Image Saver / Image Saver Metadata prompt field, and both read from the same place.

The multiline part matters more than it looks. Prompts run long and often span several lines, and String Literal preserves that formatting intact, so the exact block of text you wrote is what both the encoder and the metadata see. It's also handy as a reusable snippet holder - a quality-tag suffix, a negative-prompt boilerplate - that you define once and drop into several graphs.

The inputs and outputs that matter

• string - a multiline text field (holds full prompts, line breaks and all).

The single output is a STRING - route it to a text encoder and to the saver's positive or negative.

Installing it

ComfyUI Manager: search ComfyUI Image Saver, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/alexopus/ComfyUI-Image-Saver
cd ComfyUI-Image-Saver
pip install -r requirements.txt

Restart, hard-refresh. No downloads.

Where people get tripped up

One nuance specific to this pack: if you write LoRAs into the prompt as <lora:name:weight>, note that standard CLIP Text Encode nodes ignore that syntax - it has no effect on the actual conditioning. The Image Saver README recommends ImpactWildcardEncode from the Impact Pack for that, which converts the LoRA tags into real conditioning and leaves them parseable for the saver's hashing. So a plain String Literal is perfect for regular prompt text you want mirrored into metadata, but LoRA-in-prompt tricks need the right encoder to actually do anything.

Otherwise it's the same story as the other literals: it's only worth the node when the text truly needs to live in two places. A prompt used by one CLIP encode and nothing else can just be typed into that encode node. Reach for String Literal when you want the encoder and the saver reading the identical string - that's the case where a shared source actually buys you something, and it's precisely the accurate-metadata goal the whole pack is chasing.