apple.com Might Not Be apple.com — How Homoglyph Phishing Works
Your address bar can say "apple.com" exactly, and still be a fake site. That's because two characters can look completely identical to the human eye while being entirely different Unicode code points under the hood. This guide walks through how that optical illusion reaches all the way into the domain name system, and how browsers defend against it.
1. Homoglyphs: different characters that look the same
The Latin lowercase a (U+0061) and the Cyrillic а (U+0430) render pixel-for-pixel identically in most fonts. But to a computer they are completely different characters — different code points mean "a" !== "а" as strings. A pair of characters that look alike but carry different code points like this is called a homoglyph. Beyond Cyrillic, Greek, Armenian, and several other scripts contain letters that visually overlap with the Latin alphabet.
2. Domain names can carry Unicode too: IDN
DNS (the Domain Name System) was originally designed to handle ASCII characters only. But demand for domains in Korean, Japanese, Arabic, and other native scripts led to IDN (Internationalized Domain Name), which lets domain names contain Unicode characters. What's actually stored in DNS is a string converted into Punycode (RFC 3492), an ASCII-compatible encoding — a domain mixing in Cyrillic characters, for instance, gets stored internally as something like xn--.... The browser then decodes that Punycode back into the original Unicode characters to display it in the address bar, and it's precisely at that decode-and-display step that the illusion happens.
3. The IDN homograph attack: impersonating apple.com
а. DNS stores it as Punycode — something like xn--pple-43d.com — but the browser's address bar decodes it back to Unicode and shows "аpple.com," which is visually indistinguishable from the real apple.com. If a user enters login credentials on this fake site, they're stolen outright.
This attack isn't theoretical — security researchers have found and reported IDN homograph domains impersonating well-known brands for years — so the browser industry built defenses against it.
4. How browsers block it
Modern browsers (Chrome, Firefox, Safari, and others) will, when a domain label suspiciously mixes characters from different scripts, display the raw Punycode string (xn--...) instead of the decoded Unicode in the address bar. So instead of a natural-looking "аpple.com," the user sees the unfamiliar "xn--pple-43d.com," which is a strong visual cue that something's off. The exact heuristic differs by browser, but they generally share a common test: "is this label made up of a single, trusted script?" Some registrars also restrict which script combinations are allowed within a single domain label in the first place.
5. How to check it yourself
Browser defenses aren't 100% guaranteed, and suspicious characters can also show up in places the address bar doesn't cover — link text, an email sender name, and so on. In those cases you can paste the text into the Unicode Inspector to check it directly. The tool breaks every character in a string down to its code point (U+XXXX), so you can instantly tell whether a character that looks like "a" is actually U+0061 (Latin) or U+0430 (Cyrillic). The same trick works for spotting hidden zero-width characters like ZWSP (U+200B).
Frequently Asked Questions
Q. Can homoglyph attacks target Korean (Hangul) domains too?
A. In principle, yes. But Hangul has such a distinctive script that confusion with the Latin alphabet is far less common than with Cyrillic or Greek. Attacks against Hangul domains are more likely to exploit confusable characters within the same script — the digit 0 versus the letter O, for example.
Q. Does seeing Punycode (xn--...) always mean danger?
A. No. Legitimate multilingual domains — a real Korean-language domain, for example — are also encoded as Punycode, so an xn-- string by itself isn't a red flag. What deserves extra caution is when the browser has judged that decoding it would be unsafe and is showing you the raw Punycode as a deliberate warning.
Q. Can email sender addresses be spoofed the same way?
A. Yes — if an email client decodes and displays the domain, the sender's domain can be disguised using the exact same mechanism. Copying the suspicious sender domain text and checking its code points in the Unicode Inspector is a reliable way to verify it.
Q. Is there any way to eliminate this problem entirely?
A. Fully eliminating it is difficult, but browsers' Punycode-display policies and registrars' script-restriction policies keep getting stronger. For users, the safest habit for important login pages is to use a bookmark or type the address yourself rather than clicking a link.