Internationalized Domain Names (IDNs): Punycode, Scripts and Pitfalls

The original rules for host names allowed only ASCII letters, digits and hyphens. Much of the world, however, writes in other scripts or uses accented letters. Internationalized domain names (IDNs) let people register names such as bücher.example or names written entirely in Arabic, Chinese, Cyrillic, Devanagari or other scripts, including in some top-level domains themselves.

How IDNs work: Punycode

The DNS still works with ASCII internally. IDNs are made compatible through the IDNA standards: each non-ASCII label is converted to an ASCII representation using an encoding called Punycode and given the prefix xn--. For example, bücher becomes xn--bcher-kva. The conversion is done by browsers, email clients and other software; the DNS only ever sees the ASCII form, sometimes called the A-label, while the Unicode form is the U-label.

Length limits apply to the encoded form

The usual limits, a maximum of 63 octets per label and 253 characters for the full name, apply to the Punycode version. Because encoding adds the xn-- prefix and extra characters, a label that looks short in its native script may be much longer once encoded. Check the encoded length when choosing a name.

Which characters are allowed

Not every Unicode character can appear in a domain name. The IDNA2008 standard defines which code points are permitted, generally letters and digits used in writing systems, and excludes symbols, punctuation and most emoji. Registries then publish their own tables of accepted characters and scripts for each TLD. Many registries do not allow mixing scripts within a single label, which helps prevent confusing names.

Normalization and case

Before encoding, labels are normalized, so visually identical sequences, such as a precomposed accented letter and a letter plus combining accent, produce the same result. Some characters are handled differently between the older IDNA2003 standard and IDNA2008, for example the German sharp s (ß) and certain joiner characters. Different software may therefore treat a few edge-case names differently, which is worth testing if your name contains such characters.

Homograph attacks

Different scripts contain letters that look the same. A Cyrillic "а" and a Latin "a" are distinct characters but nearly indistinguishable on screen. Attackers can register look-alike names to imitate well-known sites. Browsers counter this with display rules: when a name mixes scripts in a suspicious way or does not match the user's language settings, they may show the Punycode form instead of the Unicode form. Registries reduce the risk with script restrictions and variant policies.

Practical considerations for owners

• Display: some browsers, apps and systems show the xn-- form, which can confuse visitors.
• Typing: visitors need a keyboard or input method for the script; consider also registering an ASCII alternative.
• Email: email addresses with internationalized domains or local parts depend on support from mail servers and clients; support has improved but is not universal.
• Certificates and services: TLS certificates and many tools work with the A-label form; make sure configuration uses consistent forms.
• Variants: some registries bundle or block variant names, for example traditional and simplified Chinese forms.

Testing an IDN

1. Convert the name to Punycode with a reliable tool or library and check its length.
2. Confirm the TLD registry accepts the script and characters.
3. Open the domain in several browsers and devices to see how it is displayed.
4. Test email delivery to and from the domain if you plan to use it for mail.

Key takeaways

• IDNs are stored in DNS as xn-- Punycode labels.
• Length limits apply to the encoded form, which is longer than it looks.
• Registries decide which scripts are allowed and often forbid mixing scripts.
• Expect differences in display and email support, and test before relying on an IDN.