The usual suspects
If two strings "should" match but don't, it is almost always one of these. The table above names them when they're the difference.
| Looks like | Could be | Where it comes from |
|---|---|---|
| a space | U+00A0 no-break space | Web pages, Word, copied spreadsheet cells |
| nothing | U+200B zero-width space, U+FEFF byte order mark | CMS editors, the first line of UTF-8 files |
| ' | U+2019 right single quote | Word and phones' "smart quotes" |
| - | U+2013 en dash, U+2212 minus | Autocorrect, typeset documents |
| é | e + U+0301 combining accent | macOS file names, some keyboards |
For whole paragraphs or files, the text compare in character mode shows the same highlights across many lines.
Questions
Why do two strings that look identical not match?
Almost always a character you cannot see or cannot tell apart: a trailing space, a non-breaking space (U+00A0), a zero-width space (U+200B), a curly apostrophe (U+2019) instead of a straight one (U+0027), an en dash instead of a hyphen, or an accented letter stored as two code points. This tool lists the code point of every differing character so you can see which.
What is the edit distance?
The Levenshtein distance: the minimum number of single-character insertions, deletions and substitutions needed to turn one string into the other. "kitten" to "sitting" is 3. It is computed for strings up to 5,000 characters.
What does "same after Unicode normalisation" mean?
Some characters can be stored in more than one way; é can be one code point (U+00E9) or e followed by a combining accent (U+0065 U+0301). They look identical but compare as different. If the tool says the strings are the same after NFC normalisation, that is your difference.
Is the comparison case-sensitive?
Yes by default, like most programming languages. Tick "Ignore case" for a case-insensitive comparison.