Internationalized Domain Names (IDNs)

An internationalized domain name (IDN) is a domain name that contains characters from non-Latin scripts or languages — such as Arabic, Chinese, Cyrillic, Devanagari, Hebrew, Japanese, or Korean — as well as accented Latin characters used in languages like French, German, Polish, or Spanish.

Before IDNs existed, the domain name system (DNS) only supported ASCII characters: the 26 letters of the Latin alphabet, digits 0–9, and hyphens. This excluded the vast majority of the world's writing systems from being represented natively in a domain name.

ICANN introduced internationalized domain names to make the internet more accessible to non-English-speaking communities. Today, IDN TLDs (top-level domains) exist for dozens of languages, allowing users to navigate the web entirely in their native script — from the domain extension all the way to the website address.

There are two distinct ways non-ASCII characters can appear in a domain name, and it is important to understand the difference:

IDN TLDs (IDN domain extensions) — These are the TLDs listed on this page. The extension itself is written in a non-ASCII script. Examples include .中国 (China), .рф (Russia), .مصر (Egypt), and .한국 (South Korea). A fully internationalized domain like 政府.中国 uses native characters at both levels — the second-level domain name and the TLD extension.

IDN domain names under standard TLDs — Some registries that operate familiar TLDs like .com, .net, or country-code TLDs like .es or .de allow the registration of second-level domain names containing non-ASCII characters, even though the extension itself remains in ASCII. For example, münchen.de or académie.fr use accented or non-ASCII characters in the domain name, but the TLD is a conventional ASCII extension.

Whether a standard TLD accepts non-ASCII registrations depends entirely on the registry's policy. Some registries permit a wide range of Unicode characters; others restrict registrations to ASCII-only second-level domains. There is no universal rule — you need to check the specific registry's IDN policy for the TLD you want.

Why this distinction matters for security: IDN homograph attacks almost always exploit the second scenario — registering a domain name that uses lookalike Unicode characters (such as a Cyrillic а in place of a Latin a) under a common ASCII TLD like .com. This creates a domain that appears visually identical to a trusted brand in the address bar. IDN TLD extensions are generally subject to stricter single-script policies enforced by the registry, which limits — though does not eliminate — this type of abuse at the extension level.

While IDN domains appear in native scripts to users, the DNS infrastructure still operates on ASCII. The bridge between the two is Punycode — an encoding standard defined in RFC 3492 that converts Unicode characters into a valid ASCII-compatible string.

Every IDN domain is stored and resolved in the DNS as its Punycode equivalent, which always begins with the prefix xn--. For example:

• The Arabic domain مثال.إختبار becomes xn--mgbh0fb.xn--kgbechtv
• The German domain münchen.de becomes xn--mnchen-3ya.de
• The Japanese domain 日本語.jp becomes xn--wgv71a309e.jp

Modern browsers and email clients automatically handle Punycode conversion, so users see the human-readable Unicode version in the address bar. Behind the scenes, the DNS resolves the xn-- Punycode string just like any other domain name.

You can use a Punycode converter to translate any IDN domain into its ASCII-compatible encoding (ACE) form — useful when configuring DNS records, SSL certificates, or server settings that require the raw ASCII representation.

Yes — IDN domain registration is available through ICANN-accredited registrars that support Unicode domain names. Not every registrar offers IDN registration, so you will need to find one that specifically supports the script and TLD you want.

What to look for in an IDN registrar:

• Support for the specific script or language character set you need (Arabic, Cyrillic, CJK, Devanagari, etc.)
• Availability of the IDN TLD you want — both generic TLDs (gTLDs) and country-code TLDs (ccTLDs) may have IDN variants
• Correct handling of Punycode conversion during the registration process
• Support for IDN-compatible SSL/TLS certificates and email configuration

Registration process: Once you have identified a registrar and confirmed availability, the process mirrors standard domain registration. The registrar automatically converts your chosen Unicode domain name into its Punycode equivalent and submits it to the registry. You manage the domain using the Unicode version in your registrar's control panel.

Pricing for IDN domains varies by TLD and registrar, and follows the same renewal model as any other domain name.

A country-code top-level domain (ccTLD) is a two-letter domain extension assigned by ICANN to represent a specific country or territory — such as .us (United States), .de (Germany), .jp (Japan), or .br (Brazil). All traditional ccTLDs use ASCII characters, meaning the extension itself is always written in the Latin alphabet regardless of the country's native script.

An IDN (internationalized domain name), by contrast, is a domain that uses non-ASCII characters — either in the second-level domain name, in the TLD extension itself, or both. IDNs exist specifically to allow the domain name system to represent the world's languages and scripts beyond the Latin alphabet.

These two categories overlap in an important way: IDN ccTLDs. ICANN began delegating IDN ccTLDs in 2010 to allow countries to represent their own extension in their native script. For example:

• .рф is the IDN ccTLD for Russia — the Cyrillic equivalent of .ru
• .中国 and .中國 are IDN ccTLDs for China in Simplified and Traditional Chinese
• .مصر is the IDN ccTLD for Egypt in Arabic
• .भारत is one of several IDN ccTLDs for India in Devanagari script

So while every IDN ccTLD is an IDN, not every ccTLD is an IDN — most country-code extensions remain ASCII-only. And while every IDN ccTLD represents a country, not every IDN is a ccTLD: IDN gTLDs (generic top-level domains) such as .游戏 (games) or .شبكة (web/network) are internationalized but not country-specific.

For a full list of country-code domain extensions — both ASCII and IDN — visit our country TLD directory.

An IDN TLD (internationalized top-level domain) is a top-level domain extension written in a non-ASCII script. Prior to ICANN's IDN program, all TLDs — including country-code TLDs like .uk or .de — were limited to ASCII characters, even for countries that do not use the Latin alphabet.

ICANN began delegating IDN ccTLDs (internationalized country-code top-level domains) in 2010. These allow countries to represent their TLD in their own native script. For example:

• .中国 — China (Simplified Chinese)
• .مصر — Egypt (Arabic)
• .भारत — India (Devanagari)
• .рф — Russia (Cyrillic)
• .한국 — South Korea (Hangul)

In addition to ccTLDs, IDN generic TLDs (gTLDs) are also available — allowing domain extensions in scripts including Arabic, Chinese, Cyrillic, Hebrew, Japanese, Korean, Tamil, Thai, and many others.

The total number of delegated IDN TLDs continues to grow as ICANN processes new applications. This page lists all currently available IDN TLDs with their supported scripts, registration status, and pricing.

An IDN homograph attack (also called a homoglyph attack) is a type of phishing where a malicious actor registers a domain name that looks visually identical — or nearly identical — to a legitimate one, but uses Unicode characters from a different script that resemble the original Latin letters.

For example, the Cyrillic letter а (U+0430) looks identical to the Latin letter a (U+0061) in most fonts. An attacker could register a domain like pаypal.com using the Cyrillic 'а', which would display identically to paypal.com in many browsers.

This type of attack typically targets standard ASCII TLDs like .com — not IDN TLD extensions — because the attack relies on mixing scripts within the second-level domain name while keeping a familiar, trusted-looking extension. See the question above for a fuller explanation of this distinction.

How browsers and registries address this:

• Modern browsers display the Punycode (xn--) version in the address bar when a domain mixes scripts, making the deception visible
• Many registries enforce single-script policies, preventing a domain from mixing characters from different Unicode scripts
• ICANN provides guidance to registries on implementing measures to reduce homograph attack risk

How to protect yourself: Always check the address bar carefully when clicking links. If a domain you trust displays an xn-- prefix or contains unexpected characters, treat it with suspicion and navigate directly to the site instead.

IDN domains can be effective for SEO when targeting audiences who search in non-Latin scripts — particularly in markets where users are more likely to type queries and brand names in their native language.

From a technical SEO perspective, search engines including Google fully support IDN domains and index them like any other domain. The Punycode and Unicode versions of an IDN resolve to the same destination, so there is no duplicate content issue.

Factors to consider:

• Local relevance: An IDN domain using the native script of your target market can reinforce local trust and brand recognition
• Keyword alignment: If users in your market search using native-script terms, a matching IDN domain may strengthen topical relevance signals
• Link building: Some platforms and older systems may have difficulty rendering or linking to IDN domains correctly — verify compatibility with your ecosystem
• Email deliverability: Not all email clients fully support IDN email addresses, so consider this if email is part of your domain strategy

For most international SEO strategies, a country-code TLD (ccTLD) or gTLD with hreflang implementation remains the primary recommendation — but an IDN TLD can be a meaningful complement when brand identity in a native script is a priority.