Internationalized domain name

Each label is converted separately. `café.example` becomes `xn--caf-dma.example`, and the `xn--` prefix marks a label as encoded.

The transformation is deterministic and reversible, so no lookup table is needed to go between the forms.

Before encoding, the name is normalised: case folding, Unicode normalisation, and rejection of characters the standard forbids. IDNA2008 defines which code points are permitted.

Registries add their own restrictions on top, typically limiting a domain to the scripts of one language to reduce ambiguity.

Browsers display the Unicode form in the address bar when they judge it safe, and fall back to showing Punycode when they do not.

DNS records, certificates, log files and most command-line tools carry the Punycode form, because that is the name on the wire.

Email addresses with international characters involve a separate specification and are supported unevenly; a domain that works for the web may not work for mail.

Both forms must be handled by anything that compares names — an allow-list checking only the Unicode form will not match the request.

Many scripts contain characters that render nearly identically to Latin ones. A Cyrillic 'а' and a Latin 'a' are different code points that look the same in most fonts.

A domain built from such substitutions is visually indistinguishable from a well-known name, which is the homograph problem.

Browsers mitigate it by displaying Punycode instead of Unicode when a name mixes scripts in suspicious ways, so a spoofed name appears as `xn--` gibberish rather than as the name it imitates.

The rules vary between browsers, which means the same domain can display differently in each — a reason to prefer an unambiguous name when one is available.

Publish canonical URLs in one form consistently. Mixing the Unicode and Punycode forms across links, canonical tags and the sitemap creates the same duplication as mixing `www` and the apex.

Check that the TLS certificate covers the name; certificates carry the Punycode form, and a mismatch there breaks HTTPS entirely.

Register the obvious ASCII equivalent as well when one exists, and redirect it, so the name is reachable by people who cannot type the characters.

Test with `dig` using the Punycode form, since most resolvers and tools expect it.