Text Compare
Check if two strings match, and how closely
- TEXT_A_PASS
- TEXT_B_PASS
- BOOLEAN
- SCORE_NUMBER
- COMPARISON_TEXT
- SCORE_FLOAT
- SCORE_INT
Text Compare takes two strings and tells you how they relate. Per the WAS README, it "compares two strings" and returns three things: a boolean for whether they're the same, a similarity score, and the text of what's similar or different between them. It's one of those rare logic-flavored text nodes - most packs give you plenty of ways to build text and almost none to reason about it - and it's specifically the node one community member went looking for alternatives to and couldn't replace when the pack broke, which tells you it fills a real gap.
You'd reach for it whenever a workflow needs to make a decision based on text. Did the caption change between two runs? Does a generated string match an expected value? How close are two prompts? The boolean output can drive a switch; the score can gate a branch; the diff text is handy for debugging what actually changed.
How it works
It runs a string comparison across the two inputs. The exact-match check is a straight equality test - same or not. The similarity score is a fuzzy measure of how alike the two strings are, so near-identical text scores high and wildly different text scores low, with everything in between. The third output surfaces the overlapping or differing portions as text so you can actually see what diverged rather than just getting a number.
The inputs and outputs that matter
- Two text inputs - the strings you're comparing.
- A boolean out - true if they're identical. Wire this into a switch or a Logic node to branch on it.
- A similarity score out - how close they are, as a number you can threshold against.
- A similarity/difference text out - the actual matching or differing content, mostly useful for inspection and debugging.
I'm naming these three outputs from the README's own description of what Text Compare returns, rather than a formal schema, so treat them as the outputs' roles rather than exact port labels.
How to install it
Part of the WAS Node Suite:
- ComfyUI Manager: search was-node-suite-comfyui, install, restart.
- Manually:
cd ComfyUI/custom_nodes && git clone https://github.com/WASasquatch/was-node-suite-comfyui/, thenpip install -r requirements.txtagainst your ComfyUI Python, and restart.
Pure text logic - no model, no heavy dependency.
Common issues
The gotcha with any string comparison is that it's literal. Whitespace, capitalization, and trailing newlines all count - "Cat" and "cat " are not an exact match, so the boolean comes back false even though a human would call them the same. If you're getting false when you expected true, normalize your inputs first (trim, lowercase) or lean on the similarity score with a threshold instead of the strict boolean. The score is the forgiving option; the boolean is the strict one.
Also be clear on which output you want. If you only need "did this change, yes or no," use the boolean. If you need "how much did it change," use the score. Wiring the diff-text output into something that expected a number is an easy mix-up given the node hands you all three at once.
And the pack caveat: WAS Node Suite has been retired since December 2023 - used everywhere, unmaintained. That very retirement is what prompted the community thread where someone lamented losing exactly these text-comparison nodes with no clean replacement. If a ComfyUI update makes every WAS node vanish with an "Import Failed", that's suite-level dependency drift, not this node. Re-run requirements.txt against the correct Python environment (or the bundled install.bat) and restart.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| text_a | STRING | First text to compare; STRING. Empty boxes count as identical. | |
| text_b | STRING | Second text to compare; STRING. Both pass through unchanged on TEXT_A_PASS and TEXT_B_PASS. | |
| mode | COMBO | Which measure to report. `similarity` scores how alike the two texts are and lists the words they share; `difference` lists the parts of text_a that changed. | |
| tolerance | FLOAT | 0.000–1 | How loosely a word counts as shared in COMPARISON_TEXT. 0.0 keeps only words appearing in both texts; 1.0 also keeps words one character apart, so 'colour' matches 'color'. |
Outputs (7)
| Name | Type | Description |
|---|---|---|
| TEXT_A_PASS | STRING | text_a unchanged, so the node can sit in the middle of a prompt chain instead of on a branch. |
| TEXT_B_PASS | STRING | text_b unchanged. |
| BOOLEAN | BOOLEAN | True only when the two texts are identical character for character. Neither the mode nor the tolerance affects it. |
| SCORE_NUMBER | NUMBER | The score, for the NUMBER inputs of the suite's own maths and logic nodes. In `similarity` mode 1.0 means identical and 0.0 means nothing in common; `difference` mode uses its own scale, which can go past 1.0. |
| COMPARISON_TEXT | STRING | The words behind the comparison, space-separated. In `similarity` mode the words the two texts have in common, and once tolerance is raised the near matches from both. In `difference` mode the parts of text_a that changed. |
| SCORE_FLOAT | FLOAT | The same score as a decimal, for a core FLOAT input. |
| SCORE_INT | INT | The score with everything after the decimal point dropped, so in `similarity` mode it is 1 only for identical text and 0 for everything else. |