Text Inspector

Features

• Finds every invisible character and its position: zero-width spaces and joiners, BOMs, soft hyphens, directional overrides, no-break spaces, ideographic spaces — 30 kinds
• Finds confusable characters (Cyrillic and Greek Latin-lookalikes) and says what each one really is and which Latin letter it resembles
• Marks confusable characters in place with the same `⟦…⟧` notation as invisible ones: `раypal` → `⟦U+0440 Cyrillic→p⟧⟦U+0430 Cyrillic→a⟧ypal`, so you can see at a glance that the third letter is really Cyrillic
• Counts characters by writing system, so an extra alphabet shows up immediately
• Checks all four normalization forms — NFC, NFD, NFKC, NFKD — and explains what “already NFC but not NFKC” means
• Detects line endings (LF / CRLF / CR) and calls out a mix, which shows up as a syntax error at a puzzling position
• Four length counts side by side: grapheme clusters, code points, UTF-16 code units (JavaScript’s .length) and UTF-8 bytes
• Optionally replaces invisible characters and confusables with markers like ⟦U+200B⟧ / ⟦U+0430 Cyrillic→a⟧ so you can paste the result elsewhere

How to use

1. Paste the text
2. Look at the “Invisible characters” and “Confusable characters” groups
3. Turn on the marking option and copy the marked text if you need to investigate elsewhere

FAQ

Why does one emoji have four different “lengths”?

Because length has four meanings. A 👍 is one character to a reader (one grapheme cluster), one code point in Unicode, two code units in a JavaScript string (a surrogate pair), and four bytes in UTF-8. Using the wrong one where it matters is the classic “truncation cut the emoji in half”. And 👨‍👩‍👧 is more extreme: one character, five code points, eight code units.

How do zero-width spaces get in?

Three common sources: copying text off a web page picks up zero-width characters used for line breaking; soft keyboards on iOS and macOS insert them with certain input methods; and messaging apps add directional marks when forwarding. They do not change what you see, but they become part of an identifier — which is why two “identical” variable names fail to compile.

What does “already NFC but not NFKC” mean?

NFKC additionally applies compatibility decomposition: fullwidth alphanumerics, ligatures (fi) and superscripts (²) are folded to their plain forms. So a text can be canonically equivalent and still contain fullwidth characters — and a fullwidth letter does not compare equal to its plain ASCII counterpart when searching, comparing or using it as an identifier. Use NFKC for data cleaning; NFC is enough when you only want accents to be spelled consistently.

Why do mixed line endings cause syntax errors?

Because most parsers treat a newline as whitespace, but some tools (older shell scripts, Makefiles, certain template engines) treat a CR as content. The extra CR from a `\r\n` then ends up inside a string or a variable name, and the error is reported at a position that makes no sense. Git’s autocrlf setting differing between machines is the usual origin of such files.

Why are fullwidth letters, or the Japanese long-vowel mark, not reported as confusables?

Because the test is deliberately conservative: a character counts only when the character it resembles belongs to another writing system. Cyrillic а resembles Latin a (Cyrillic is not Latin) and Greek Ο resembles Latin O (Greek is not Latin) — those are the real homoglyph attacks. A fullwidth Latin letter and a plain a are both Latin, differing only in width form: that is a normalization matter (NFKC handles it, and this tool reports it separately under Normalization), not a phishing one. The Japanese long-vowel mark (U+30FC) merely resembles some symbol and is not a cross-script homoglyph either. We would rather under-report than bury the Cyrillic letters you actually care about under a warning about every fullwidth letter in a Chinese text. The trade-off is that a genuinely Russian or Greek passage will have its letters flagged too — but such text is vanishingly rare in what this tool is for.