h4 - Visual Tokenizer

Why does (word:1.2) sometimes do nothing, and why do certain prompts behave like the model is ignoring half the sentence? Because of tokens. CLIP doesn't read your prompt as words - it splits it into token IDs, and how that split lands is often the difference between a prompt that works and one that silently degrades. H4_VisualTokenizer is a debug node that shows you that split: you feed it your prompt and your CLIP model, run it, and it displays exactly how the model tokenizes the text and where the weights land.

The node description says it plainly: "This node will show you EXACTLY how the model breaks down your words (tokens) and applying weights (e.g. (word:1.2))." It's the kind of tool you use once, go "oh, that's why," and then keep around for the next time a prompt misbehaves.

How it works

It runs the same pipeline ComfyUI itself uses. First it parses your text with the standard weight parser (token_weights, the thing that turns (word:1.2) into a weighted segment). Then it digs through the CLIP object - handling the SD1.5 vs SDXL vs Flux wrapper differences - to find the underlying HuggingFace tokenizer and tokenize each weighted segment. Finally it pushes the breakdown to the node's UI, where the JavaScript renders it as a visual list: each token, its token ID, and the weight applied to it.

The text output is a passthrough of your original prompt, so you can drop this node inline without altering the string it carries.

The inputs that matter

• clip (CLIP, required) - the CLIP model to tokenize with. Use the same one you're encoding the prompt with, or the tokenization won't match what actually runs.
• text (STRING, multiline, required) - the prompt to analyze.

Outputs: text (STRING) - passthrough.

The catch in the description is worth repeating: "Please wait for the node to run to see the visualization." The breakdown doesn't appear until you queue the workflow - it's rendered from an actual run, not typed in as you go.

Installing h4_Live

Part of the h4_Live pack. ComfyUI Manager: search h4_Live, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/m3rr/h4_Live

Restart. No model files, no pip extras.

Common issues

• "Wait for the node to run" is literal. If you connect it and see nothing, you haven't queued yet. It's an output node, so it fires on every run - the visualization updates each time.
• It needs a CLIP it can reach into. The node walks known wrapper structures to find the tokenizer. With an exotic loader or a CLIP that hides its tokenizer, it logs a warning and falls back to showing the raw weighted segments without token IDs. Not a crash, just less detail.
• It shows the split, it doesn't fix it. The value is diagnosis. If you spot a word being torn into subword fragments across a 75-token boundary, or a (word:1.2) that's being applied to a fragment instead of the whole word, that's your clue about why the prompt behaves oddly - then you adjust the prompt, not the node.
• Token counts differ by architecture. SD1.5's 75+2 limit and SDXL's handling aren't the same; the node will reflect whatever your actual CLIP does, which is precisely why you should analyze with the same model you generate with.
• It's a CLIP-tokenizer tool, and some modern models don't use CLIP. This visualization is meaningful for CLIP-based models (SD 1.5, SDXL, Illustrious, Pony, and the Flux-style CLIP-L side). The newest LLM-encoded models (Z-Image, Flux 2 Klein, Anima, Krea 2) wrap your prompt in a chat template and feed it to a text LLM - there's no 77-token CLIP boundary, and (word:1.2) weights are silently discarded. Run those through this node and the tokens you see won't reflect how the model actually reads the prompt. Knowing which side of that line your model is on is half the battle.