Punycode isn't just an academic curiosity — it's the reason a domain that looks like xn--pple-43d.com in a raw log or terminal can register as a nearly perfect visual copy of a well-known brand once a browser decodes it back to Unicode.
How the encoding actually works
Punycode takes the non-ASCII characters in a label, strips them out, and appends an encoded representation of their positions and code points after a hyphen, prefixed with xn--. The algorithm (RFC 3492) is fully reversible and deterministic — the same input always produces the same output, which is why security tools can flag suspicious IDN labels automatically instead of relying on a manual blocklist.
Why browsers disagree on when to decode it
Chrome, Firefox, and Safari each apply their own "IDN display algorithm": a domain is shown in readable Unicode only if all its characters belong to a single script the browser trusts for that TLD, or belong to a small set of allowed mixed scripts (like Japanese, which legitimately mixes kanji, hiragana, and katakana). Mix Cyrillic and Latin in the same label, and most browsers fall back to showing the raw xn-- form — a defense that didn't exist in the early 2000s and was added specifically in response to homograph phishing.
Common use cases
- Decoding a suspicious
xn--...string from an email header or access log to see what domain it actually represents. - Encoding a non-Latin domain before registering it or adding a DNS record.
- Debugging TLS certificate mismatches on internationalized domains.
The 2005 Unicode domain hijack
The homograph risk isn't theoretical: in 2005, security researchers demonstrated that a domain registered with Cyrillic look-alike letters could decode to what looked exactly like www.paypal.com, passing right through browser address bars of that era with no warning at all. That single proof-of-concept is why every major browser vendor now ships some form of mixed-script detection.