Internationalized domain name (IDN) explained

A Sri Lankan website using a Sinhala IDN domain

An Internationalized Domain Name (IDN) contains a non-ASCII label, such as one written in Arabic, Chinese, Cyrillic, Devanagari, Tamil or Thai, or the ASCII encoding of that label. IDNA and registry rules determine which characters can be used; Unicode support alone doesn't make a name registrable¹².

Traditional internet hostnames use ASCII letters, digits and hyphens³. DNS itself can carry arbitrary binary labels; the narrower rules come from applications that use domain names⁴. IDNA uses Punycode to represent valid non-ASCII labels within those hostname conventions. Browsers decide separately whether to display Unicode or the encoded form.

How IDN works

When you type something like münchen.de into your browser, a four-step pipeline kicks in before anything reaches the DNS.

The IDN resolution pipeline from Unicode input to DNS query

IDNA processing — Browser URL processing uses Unicode's UTS #46 compatibility processing. IDNA 2008 defines character validity and contextual constraints, including bidirectional text rules from RFC 5893 for Arabic and Hebrew domains²¹⁵.

Punycode encoding — Each valid non-ASCII label is encoded with Punycode. The algorithm copies its ASCII characters, adds a hyphen if it copied any, then encodes the non-ASCII characters as an alphanumeric sequence⁶. IDNA leaves ordinary ASCII-only labels in their ASCII form.

ACE prefix — The encoded label gets the xn-- prefix to flag it as an internationalized name⁷.

DNS lookup — The resulting string (xn--mnchen-3ya.de in our example) gets sent to the resolver. The DNS has no idea it's dealing with an IDN — it just sees a normal ASCII label.

Users can type in their own script while the browser handles conversion. The address bar may show Unicode or xn--, depending on the browser's display rules and settings.

How to register an IDN domain

This is the part that most guides skip, so here's the practical rundown.

IDN registration process overview

Pick your domain name in native script. Decide what you want — bücher.de, 中文.com, تست.ws, whatever. Keep in mind that the Punycode form is what DNS stores, and it's subject to the 63-byte label limit from RFC 1035³. A very long Unicode string can easily exceed that once encoded.

Check if your TLD supports IDN. The 2024 IDN World Report reported support at about 85% of ccTLDs and 41% of gTLDs⁸. Its regional figures were around 88% for Europe, 87% for Asia and 68% for the Americas. Check the registry's current policy before choosing a name. A fully internationalized address — such as one under .中国 or .рф — also needs an IDN TLD.

Find a registrar that handles your chosen IDN. Check its supported TLDs and character sets. A registrar may accept Unicode input and convert it to the ACE form, or ask for Punycode directly⁹. It may also ask for a language or script tag to select the registry's published IDN table¹⁰.

Test before you commit. This is my honest advice: before you register, check whether your email provider, your CMS, your contact forms, and your analytics tools can handle the domain. Universal Acceptance is still a real problem (more below), and discovering that your email bounces or your login forms reject the address after you've paid for the domain isn't fun.

IDN top-level domains

For the first decade of IDN, the internationalization stopped at the second level. You could have münchen.de, but .de stayed Latin. The logical next step was internationalizing the top-level domain itself.

ICANN approved the IDN ccTLD Fast Track Process in October 2009, and applications opened the following month¹¹. Egypt, Russia, Saudi Arabia, and the UAE were first through evaluation.

On May 5, 2010, the first IDN ccTLDs went live — all three in Arabic script¹²:

• مصر — Egypt
• السعودية — Saudi Arabia
• امارات — UAE

Russia's Cyrillic .рф followed on May 12, 2010. When general registration opened in November that year, over 240,000 domains were registered on the first day¹³.

As of mid-2025, 151 IDN TLDs span 37 languages and 23 scripts¹⁴:

A brief history

Key milestones in IDN development

The idea goes back to December 1996, when Martin Dürst at the University of Zürich proposed UTF-5 — the first known ASCII-compatible encoding for domain names¹⁵. It was rough, but the core idea was right.

The first working prototype came from Singapore in 1998. Tan Tin Wee and his team at the National University of Singapore built a functional multilingual DNS they called iDNS, demonstrating that Chinese, Malay, and Tamil scripts could work in domain names¹⁶. James Seng, a former student of Tan Tin Wee, led the commercial implementation at i-DNS.net International. But multiple competing proprietary systems created interoperability headaches.

The IETF formed its IDN Working Group in January 2000 to sort out the mess. After evaluating several competing encodings — RACE, DUDE, LACE, and others — the group picked Adam Costello's Punycode algorithm⁶. In March 2003, the first complete standard shipped as IDNA 2003 (RFCs 3490-3492)⁷.

IDNA 2003 was tied to Unicode 3.2 and mapped German Eszett (ß) to "ss" and Greek final sigma (ς) to regular sigma². The revised IDNA 2008 (RFCs 5890-5895, published August 2010) permits ß and ς and derives character validity from Unicode properties, allowing its tables to evolve with Unicode¹¹⁷.

Security: the homograph problem

Characters from different scripts can look alike. For example, аpple.com uses Cyrillic "а" (U+0430) instead of Latin "a" (U+0061). If registry rules permit the name, an attacker can use that resemblance in an IDN homograph attack, described by Gabrilovich and Gontmakher in 2002¹⁸.

Simplified IDN display checks; exact rules vary by browser

Defenses work at several layers:

Browsers apply IDN display policies independently of registration. Chrome and Firefox check script combinations and confusable characters; permitted mixtures include combinations used in Japanese names¹⁹²⁰. A label can also be a whole-script confusable: its letters belong to one non-Latin script but resemble a Latin name.

Registries restrict what can be registered through character tables, script rules and variant policies. ICANN published version 4.1 of its IDN Implementation Guidelines in November 2022; it took effect for contracted gTLD registries in April 2025¹⁰¹⁴.

ICANN itself prohibits any IDN TLD string that could be confused with an existing TLD¹¹.

An email or messaging app may display a link differently from the browser's address bar. Check the underlying domain before entering credentials. A password manager's domain matching can help flag a mismatch, though its matching and autofill settings matter.

Universal Acceptance: the real bottleneck

Standards exist. They work. Getting the rest of the software ecosystem to comply is the hard part.

Universal Acceptance (UA) means that all domain names and email addresses — regardless of script, length, or TLD — should be handled correctly by every application. In practice, that's not what happens. Forms reject non-ASCII email addresses. Databases truncate IDN domains. Validation libraries choke on long TLDs²¹.

The numbers aren't encouraging: as of 2024, only about 28% of mail servers across gTLD domains supported internationalized email addresses²². ICANN transitioned its Universal Acceptance advocacy from the UASG to a new President's Committee in 2025, signaling a shift in strategy²³.

The 2024 IDN World Report identifies Universal Acceptance as critical to IDN uptake⁸. A registrable name is of limited use if the services its owner needs reject it.

Adoption: where things stand

The 2024 IDN World Report estimated about 4.4 million second-level IDN registrations worldwide — roughly 1.2% of the global domain market⁸. These are historical figures, rather than a current registration count.

The reported distribution was uneven. Chinese script accounted for 49% of IDN registrations under gTLDs, followed by Latin-with-diacritics at 28%²⁴. The 2024 World Report identified Russia's .рф, Germany's .de and China's .cn as major ccTLDs for IDN registrations⁸.

The report described generally slow growth, with registries rating end-user awareness at an average of 2.5 out of 5⁸. Registration support and application support remain separate problems.

It's a chicken-and-egg problem that's been stuck in the same loop for years. But 151 IDN TLDs across 23 scripts is real infrastructure. The plumbing is there. The adoption just hasn't caught up yet.

Updated: September 7, 2026