Text Padder (Mikey)

A small, single-purpose node: it takes a string and stretches it out to a target character length, one of two ways you choose. Nothing fancier than that, but it's worth knowing exactly what "stretches out" means here, because the two techniques behave very differently.

The two techniques

Set technique to pad and the node appends copies of padding_character (a comma by default) to your text until it hits the target length. Your original text stays intact at the front; everything after it is filler.

Set it to repeat instead, and the node repeats your entire input text until it reaches the target length - so a short phrase becomes that phrase over and over, not your phrase plus punctuation filler. These produce very different results downstream, so pick deliberately rather than by habit.

Notice that padding_character is the exact same field name, with the exact same comma default, as the one on SD3TextConditioningWithOptionsOnePrompt elsewhere in this pack. That's not a coincidence worth over-reading, but it is a real, visible link between the two nodes: if you're working with SD3's per-encoder padding options and want to pre-process a prompt's length before it hits the conditioning node, this is a natural companion to reach for.

Inputs and output

• text - the string you're padding, defaulting to "text to pad" until you fill it in.
• length - target character count, 1 to 1000, default 512.
• technique - pad or repeat, described above.
• padding_character - what gets used as filler under the pad technique; a comma by default, but any character or short string works.

Output: padded_text, a single string at (or as close as possible to) your target length, ready to feed into a CLIP Text Encode or any downstream text-processing node.

Installing it

Through ComfyUI Manager, search "Mikey Nodes." Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/bash-j/mikey_nodes

Restart ComfyUI. No dependencies or model files needed - this is plain string manipulation, nothing more.

Things worth knowing before you use it

Padding a prompt out with filler characters isn't free on CLIP-based models - those extra commas or repeated characters still consume tokens inside your encoder's context window. On SD3's CLIP-L and CLIP-G in particular, that window hard-caps at 77 tokens and degrades ugly (not gracefully) once you go over, so padding a prompt that's already close to the limit can push it past the point where the encoder starts truncating in a way you didn't intend. If you're padding for length reasons rather than for a specific technical need (like matching a downstream system's expected input length), check your token count isn't the thing actually breaking.

The repeat technique in particular can produce genuinely strange output if your source text is long relative to your target length - you might end up with a truncated mid-word cutoff at the boundary, since the node isn't aware of word boundaries when it stops. If that matters for your use case, keep length comfortably above a whole multiple of your source text's character count.