Internationalized Domains and Punycode: Why Some Domains Start with xn--

Classic DNS was built for a 63-character ASCII label: letters a–z, digits and the hyphen. Nothing else fits. Internationalized domain names (IDNs) work around this with the IDNA algorithm: the Unicode name is normalised and converted to an ASCII form called Punycode, always prefixed with xn-- so resolvers recognise it. The Persian name پارسی.ایران becomes xn--mgba3a4f16a.xn--mgba3a4f16a on the wire; German münchen.de becomes xn--mnchen-3ya.de; Japanese 日本.jp becomes xn--wgv71a.jp. Both forms refer to exactly the same domain — the pretty one for humans, the xn-- one for the protocol.

The opportunity side

• Native-language branding: a brand can hold a domain that matches its name in its customers’ own script, which is easier to type, remember and advertise locally than a transliterated Latin version.
• Search visibility: engines match native-script queries against native-script domains, and local users tend to trust and click them more.
• Script TLDs: several registries operate fully native top-level domains, so an IDN can be native end to end.

The homograph risk

Many characters across scripts look identical or nearly identical: Latin a and Cyrillic а, the digits 1, l and uppercase I, or visually similar Arabic and Persian letters. A registrant can therefore create a domain that renders like a famous brand but is a different, attacker-owned string — the classic homograph (spoofing) attack. Browsers defend in two ways: mixed-script domains are displayed in punycode form, and registries block many confusable registrations — but pure single-script lookalikes still exist, so аpple.com with a Cyrillic first letter can look identical to the original in an address bar.

Normalization: the part that bites

IDNA conversion is not a simple character swap. The standard (IDNA2008, with UTS #46 mapping in browsers) first normalises the name: it folds case, maps some disallowed characters, and rejects others entirely. Consequences show up in real work: a domain registered in uppercase still lives in punycode as lowercase; Turkish dotless i and similar locale-specific letters can produce different punycode than expected; zero-width joiners in emoji domains make visually identical names that differ byte by byte. Copy-paste a name from a document and it may contain a hidden character that breaks the lookup — always retype or convert it rather than trusting what looks the same.

Practical rules

1. Always check both forms. DNS tools, WHOIS and certificates operate on the punycode form, while your marketing uses the Unicode form; a mismatch between the two is how broken lookups and wrong certificate names happen.
2. Check the certificate subject: it must contain the punycode form (xn--), not the raw Unicode.
3. Before registering a native-script domain, test the punycode rendering in several browsers — that is what your users will see in edge cases.
4. When auditing links in emails, decode every xn-- label before trusting it; that is the fastest homograph screen there is.

The WhoDNS punycode converter switches between Unicode and punycode in both directions instantly, so you can confirm what a domain really is before a lookup, a purchase or a click.

🔗 Related tool: Convert between Unicode and Punycode