# Homograph attack Canonical URL: https://offlineutils.com/glossary/homograph-attack Also known as: IDN homograph attack, homoglyph attack, script spoofing, lookalike domain, confusable domain Published: 2026-10-23 Publisher: offlineutils.com > A homograph attack uses characters that look identical to others — Cyrillic а in place of Latin a — so that a different domain, username or identifier appears to be a trusted one. Browsers defend domain names by showing the xn-- form of names that look suspicious instead of the Unicode spelling. Unicode contains many characters that render identically, or nearly so, in common fonts. Cyrillic а, е, о, р, с and х are indistinguishable from Latin a, e, o, p, c and x, and Greek ο from Latin o. Because they are different code points, a domain spelled with them is a different domain — one anyone can register — that looks exactly like the real one in an address bar, an email link or a chat message. Evgeniy Gabrilovich and Alex Gontmakher described the attack in Communications of the ACM in 2002. The attack comes in two shapes, and the second is the one that defeats simple checks. A mixed-script spoof swaps in a single foreign letter, as in аpple.com with a Cyrillic а, which encodes to xn--pple-43d.com; it is detectable because one label mixes Latin and Cyrillic. A whole-script spoof builds the entire label from one script. In April 2017 Xudong Zheng registered xn--80ak6aa92e.com, spelled entirely in Cyrillic, and Chrome 57, Firefox 52 and Opera displayed it as apple.com. There was no mixing to detect. Chrome 58 closed that gap the same month. The defences that hold are about display and exact matching, not blocking. Browsers apply policies that fall back to the xn-- form when a label mixes scripts suspiciously or is made entirely of lookalikes for Latin letters under a non-matching top-level domain. Unicode's UTS #39 supplies the data behind such checks: confusables.txt maps every character to a skeleton, two strings with the same skeleton are confusable, and the standard defines mixed-script and whole-script detection on top of it. Password managers are a strong practical defence because they fill credentials by exact domain, so on a lookalike they find nothing and fill nothing. The same trick works anywhere text stands in for identity: usernames and display names, package names in a registry, email sender names, and identifiers in source code. Exact string comparison cannot catch it, and neither can Unicode normalization, because Cyrillic а and Latin a are different letters rather than different encodings of one. Any system that shows user-chosen names as identities should compare UTS #39 skeletons when a name is registered, and refuse a new name that collides with an existing one. ## Frequently asked questions ### How can I tell whether a domain is a homograph? Look at its ASCII form. A lookalike that contains non-Latin letters has an xn-- label — аpple.com with a Cyrillic а is really xn--pple-43d.com — so converting it with a Punycode converter exposes it. If your browser shows an xn-- name where you expected a readable one, treat that as the warning it is. A password manager declining to fill your credentials on a familiar-looking site is another strong signal. ### Do browsers protect against homograph attacks? Partly, through display policies rather than blocking. Chrome, Firefox and Safari each show the xn-- form for names that look suspicious, such as a label mixing Latin and Cyrillic, or one made entirely of Cyrillic letters that resemble Latin ones under a non-Cyrillic top-level domain. Those policies were tightened after real bypasses — the all-Cyrillic apple.com lookalike displayed as apple.com in Chrome 57 and was fixed in Chrome 58 — and they differ between browsers, so passing them is not proof that a name is legitimate. ### What is the difference between mixed-script and whole-script confusables? A mixed-script confusable combines letters from more than one script in a single label, such as Latin pple with a Cyrillic а, and can be caught by checking for the mixture. A whole-script confusable uses only one script throughout, such as an all-Cyrillic string that reads as apple, so there is no mixture to detect. Catching it requires knowing which strings in one script look like words in another, which is what UTS #39's whole-script confusable data provides. ### Is this only a problem for domain names? No. Anywhere a user-chosen name stands in for identity is exposed: usernames and display names, package names in a registry, email sender names, and identifiers in source code. The defence is the same everywhere — compute the UTS #39 skeleton of each name when it is registered and reject one that collides with an existing name — because exact comparison treats a lookalike as a different, perfectly valid string. ### Does Unicode normalization prevent homograph attacks? No. Normalization, even the aggressive NFKC form, unifies different encodings and formatting variants of the same character, but Cyrillic а and Latin a are different letters in different scripts, and no normalization form maps one to the other. Detecting lookalikes needs confusable data — UTS #39's skeleton mapping — applied on top of normalization, not instead of it. ## Related tools - https://offlineutils.com/punycode-converter - https://offlineutils.com/url-parser ## References - https://en.wikipedia.org/wiki/IDN_homograph_attack - https://www.unicode.org/reports/tr39/ - https://chromium.googlesource.com/chromium/src/+/main/docs/idn.md