Unicode Confusables Checker

Homoglyphs, skeletons, and what a confusables check actually proves

A homoglyph attack does not break anything. It relies on the fact that Unicode contains many characters that are drawn the same way and are not the same character. Cyrillic а, Greek ο, Cherokee Ꮮ and Latin a, o and L are separate letters with separate code points, separate scripts and, in most typefaces, identical shapes. A string built from them reads as one word to a person and compares as a different word to a computer. That gap is the whole attack, and it exists wherever a human being reads an identifier and trusts it: domain names, package names, usernames, filenames, email display names.

The skeleton, and why it must never be stored

Unicode's answer is in UTS #39, Unicode Security Mechanisms. It publishes a table mapping each confusable character to a prototype — an exemplar for the class of characters that look like it — and defines a skeleton operation that decomposes a string, drops the invisible characters, replaces each remaining character with its prototype, and recomposes. Two strings are confusable when their skeletons are equal. It is a deliberately blunt instrument: it imposes transitivity, so it is sometimes over-inclusive, and it is not a similarity score.

The part that gets missed is that the table moves. This tool is pinned to Unicode 17.0.0, whose confusables file carries 6,565 mappings; Unicode 16.0.0 carried 6,355. Two hundred and ten mappings were added and thirty-nine were repointed at a different prototype. One of the thirty-nine is U+04CF CYRILLIC SMALL LETTER PALOCHKA, whose prototype changed from Latin i to Latin l — and the palochka is a character in the most-cited lookalike domain ever registered. Under Unicode 16.0.0 that label's skeleton was appie. Under 17.0.0 it is apple. The standard says so plainly: skeletons are not stable across versions and must be recomputed on upgrade. A cached skeleton column in a database is a comparison against last year's idea of what looks alike.

Eight of the 6,565 confusable sources are plain ASCII. 0 maps to O, 1 and I and the pipe all map to l, and m maps to the two-character sequence rn — which is why the same algorithm built for cross-script attacks catches the oldest typosquat in the book.

Normalisation is not a substitute, in either direction

The common first instinct is Unicode normalisation — NFKC — which folds fullwidth letters, ligatures and mathematical alphabets back toward plain ASCII. It does not touch the cases that matter here. Cyrillic а, е, р and с pass through NFKC completely unchanged, because they are not compatibility variants of anything: they are separate letters that happen to be drawn identically. A reverse gap exists too. All ten fullwidth digits, U+FF10 through U+FF19, fold under NFKC and have no confusables row at all — and the letters are only partly covered in the other direction: 31 of the 52 fullwidth ASCII letters carry a row and 21 do not. Neither transform contains the other, and neither is complete on its own, which is why the panel above splits your input into three columns rather than claiming one check is enough.

Restriction levels, and the case they cannot catch

UTS #39 also defines six restriction levels, from ASCII-Only up to Unrestricted, based on which scripts a string draws on. They are useful and they are frequently oversold. Mixing one Cyrillic letter into a Latin word produces a mixed-script string that the levels catch immediately. A label written entirely in Cyrillic does not: it is perfectly consistent, it qualifies as Single Script, and it passes every level except ASCII-Only. The standard's own worked example is a Cyrillic string that reads as “Circle”. Restriction levels ask whether a string is internally consistent. A well-built impersonation always is. That is why this tool reports the level and the skeleton side by side, and flags the combination — single-script and full of remapped characters — rather than letting a clean level read as a clean bill of health.

One more reading trap worth naming: a level of Unrestricted usually means nothing sinister. The algorithm's first test is whether every character is even permitted in an identifier, and ordinary punctuation is not. Type a sentence with a space in it and the answer is Unrestricted, because a space cannot appear in an identifier — not because the sentence is dangerous. The tool names the offending characters rather than leaving you to guess.

Why this matters more in a multi-script region

Southeast Asia is one of the most script-dense regions on the internet. Thai, Khmer, Lao, Burmese, Tamil, Chinese, Jawi-script Malay and Latin-with-diacritics Vietnamese are all in daily commercial use, frequently on the same page as English. The IANA root zone currently delegates 1,438 top-level domains, of which 151 are internationalised xn-- labels — and ASEAN is well represented among them: .ไทย for Thailand, .新加坡 and .சிங்கப்பூர் for Singapore, and .مليسيا for Malaysia are all live. Registries that permit non-Latin labels are doing the right thing for the people who read those languages, and the same policy widens the space a lookalike can hide in. A Singapore or Malaysian brand whose name is legitimately written in two scripts cannot be protected by a rule that simply forbids script mixing; the honest defence is to compare skeletons against the names you actually own, and to look at what a label decodes to rather than at what it renders as.

What this tool does not do

It does not detect Trojan Source (CVE-2021-42574). That is a different attack: bidirectional control characters that make source code render in one order and compile in another. Nothing in it looks like anything else — the deception is positional, not visual. It also computes the pre-bidi form of the skeleton, which UTS #39 equates to the full definition for any string without a strong right-to-left character; when your input contains one, the page says so rather than presenting a value it has not earned. And the punycode panel shows the form a label produces, not whether a registry would accept it: that needs the full UTS #46 mapping and validity rules, which are a separate body of data.