Internationalized domain name (IDN) explained

A Sri Lankan website using a Sinhala IDN domain

An Internationalized Domain Name (IDN) is a domain name that contains at least one character outside the basic a-z, 0-9, and - range that the DNS was built for. That sounds like a small tweak, but it unlocks domain names in Arabic, Chinese, Cyrillic, Devanagari, Tamil, Thai -- any script that Unicode supports.

The DNS, designed in 1983, only speaks ASCII¹. For most of the internet's history, that meant web addresses were written exclusively in Latin characters. If your language uses a different alphabet, tough luck -- you had to memorize strings of foreign glyphs to get around the web. IDN was the fix for that. Under the hood, it uses a clever encoding called Punycode to squeeze non-ASCII characters into a format DNS can handle, while browsers show the human-readable version.

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 -- The browser validates each character against the IDNA rules. Under the current standard (IDNA 2008, published in RFC 5890), this means checking every Unicode code point against a set of derived property tables and applying context-dependent rules -- for instance, bidirectional text rules from RFC 5893 for Arabic and Hebrew domains²³.

Punycode encoding -- Each domain label that contains non-ASCII characters gets run through the Punycode algorithm. ASCII-only labels pass through unchanged. The algorithm separates out the ASCII characters, appends a hyphen delimiter, then encodes the non-ASCII characters as a compact alphanumeric sequence⁴.

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.

The whole thing is transparent. Users type in their own script, the browser handles the conversion silently, and the DNS resolves it like any other domain. You only see the xn-- form if the browser explicitly decides to show it (which happens when it suspects something fishy -- more on that in the security section).

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. About 85% of ccTLDs and 41% of gTLDs accept IDN registrations as of 2025⁶. The support is good in Europe and Asia (around 88% and 87% of registries), weaker in the Americas at 68%. If you want a fully internationalized address -- like something under .中国 or .рф -- you're looking at an IDN TLD, which is a different pool of options.

Find a registrar that handles IDN. Not every ICANN-accredited registrar supports IDN. Look for ones that are specifically certified for it. Most will let you type the domain in its native script directly; the registrar converts it to Punycode and submits the ACE form to the registry⁷. Some registrars require you to select an IDN language tag during registration -- this is an ICANN requirement that helps enforce script-specific rules.

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¹⁰. That's still the most successful IDN TLD launch by a wide margin.

As of mid-2025, there are 151 IDN TLDs spanning 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 had a significant flaw, though: it was hardwired to Unicode 3.2 and made some questionable character mappings. The German Eszett (ß) got silently mapped to "ss", and the Greek final sigma (ς) merged with regular sigma. For a standard meant to respect local languages, that was a real miss¹⁴. The revised IDNA 2008 (RFCs 5890-5895, published August 2010) fixed these issues by defining per-character validity based on Unicode properties rather than explicit mapping tables, making the standard future-proof across Unicode versions².

Security: the homograph problem

IDN's biggest strength -- visual similarity to native text -- is also its biggest vulnerability. Unicode has thousands of characters across hundreds of scripts, and many look identical or near-identical to Latin letters. An attacker can register аpple.com using a Cyrillic "а" (U+0430) instead of Latin "a" (U+0061), and most people won't spot the difference. This is the IDN homograph attack, first described by Gabrilovich and Gontmakher in 2002¹⁵.

Browser decision tree for IDN display

Defenses work at several layers:

Browsers are the frontline. Chrome, Firefox, and Edge all implement IDN display policies that fall back to showing the raw xn-- Punycode when something looks suspicious. The general rule: if a domain label mixes scripts (Latin + Cyrillic, for instance), show Punycode. Browsers also maintain confusable-character databases and apply script-specific heuristics¹⁶¹⁷. Chrome tightened its rules significantly starting with version 59, though research has shown gaps remain -- particularly with "whole-script confusables" where every character in a label comes from the same non-Latin script but mimics a Latin domain.

Registries restrict what can be registered. Many require single-script labels and tie registrations to language communities. ICANN's IDN Implementation Guidelines, updated to version 4.1 in April 2025, added stronger protections against consumer confusion and DNS abuse¹⁸.

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

None of these defenses are perfect, though. Homographic URLs distributed via email or messaging apps render normally -- the browser protections only kick in once you actually navigate to the URL. A password manager is actually one of the better defenses here: it won't autofill credentials on a Unicode lookalike domain because the underlying Punycode doesn't match.

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²¹.

68% of ccTLD registries say Universal Acceptance is the single most important factor for IDN uptake -- ahead of end-user awareness⁶. Which makes sense: why register a domain in Hindi if half the internet's contact forms refuse to accept it?

Adoption: where things stand

Despite two decades of standardization, IDN accounts for about 4.4 million second-level registrations worldwide -- roughly 1.2% of the global domain market⁶. That's remarkably low given that the majority of the world's population doesn't use Latin script as their primary writing system.

The distribution is heavily skewed. Chinese script makes up 49% of IDN registrations under gTLDs, followed by Latin-with-diacritics at 28%²². The top ccTLD IDN holders are Russia's .рф (~769,000 domains), Germany's .de with diacritics (~648,000), and China's .cn (~537,000).

Growth is essentially flat. Median IDN registration growth across 41 ccTLDs was 0.6% in 2023⁶. End-user awareness scores an average of 2.5 out of 5 when ccTLD registries are asked to rate it. Most people simply don't know they can register domains in their own script -- and the ones who do often find the Universal Acceptance situation discouraging enough to stick with ASCII.

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: March 16, 2026