Punycode and Internationalized Domain Names

1. What Punycode Does

The Domain Name System (DNS) only supports a restricted subset of ASCII: lowercase letters a-z, digits 0-9, and the hyphen. No accented characters, no Chinese ideographs, no Cyrillic. Punycode (defined in RFC 3492, March 2003) is the encoding that translates any Unicode string into this restricted ASCII format so internationalized domain names (IDNs) work within the existing DNS infrastructure.

Every Punycode-encoded label starts with the prefix xn--, which signals to DNS resolvers that the label contains encoded Unicode. The browser converts between the user-visible Unicode form and the Punycode form transparently. You never see xn-- in the address bar under normal conditions.

2. How the Encoding Works

Punycode's algorithm is built on six constraints: completeness (must handle any valid Unicode string), uniqueness (one Unicode input produces exactly one ASCII output), reversibility (the original Unicode can be recovered), efficiency (keep the ASCII output short), simplicity (DNS resolvers must process it quickly), and readability (avoid misleading ASCII sequences where possible).

The algorithm works in two phases. First, it copies any ASCII characters from the original domain name directly into the output and inserts a hyphen separator. Then it encodes the positions and values of non-ASCII characters using a variable-length integer encoding called Bootstring. The result is a string like xn--mnchen-3ya where the "mnchen" part is the ASCII skeleton and "3ya" encodes the position and identity of the u-umlaut.

3. Real-World Examples

Unicode Domain	Punycode	Script
Munchen.de	xn--mnchen-3ya.de	Latin + umlaut
cafe.fr	xn--caf-dma.fr	Latin + accent
manana.com	xn--maana-pta.com	Latin + tilde
resume.com	xn--rsum-bpad.com	Latin + accents
test.kr (Korean)	xn--9n2bp8q.kr	Hangul
hello.jp (Japanese)	xn--4pvxs.jp	Hiragana
Beijing.cn (Chinese)	xn--1lq90ic.cn	CJK

Notice how Latin-based domains keep most of their readable characters in the output. CJK and other non-Latin domains produce shorter but less recognizable Punycode strings because none of their characters are ASCII. Use the text to ASCII tool to see which characters in a domain name fall within the ASCII range and which require Punycode encoding.

4. Homograph Attacks

Punycode's biggest security risk is the homograph attack. Cyrillic "a" (U+0430) and Latin "a" (U+0061) look identical in most fonts but have different Unicode code points. An attacker can register a domain like "apple.com" using Cyrillic characters. The browser encodes it as xn--80ak6aa92e.com via Punycode, but displays the Unicode form - which looks exactly like the real apple.com.

This is not theoretical. In 2017, researcher Xudong Zheng demonstrated a proof-of-concept domain using all-Cyrillic characters that Chrome, Firefox, and Opera all displayed as "apple.com" in the address bar. The demonstration forced browser vendors to change their IDN display policies.

5. How Browsers Defend Against Homographs

Modern browsers use heuristics to decide whether to show the Unicode form or the raw Punycode. Chrome's policy (documented in chromium.org/idn) checks whether all characters come from the same script as the domain's TLD. If a .com domain mixes Latin and Cyrillic characters, Chrome shows the Punycode form (xn--...) instead of the deceptive Unicode version.

Practical defenses for users:

• Bookmark sites where you enter sensitive data (banking, email, cloud accounts)
• Check for the xn-- prefix when a URL looks suspicious
• Keep browsers updated - IDN policies change with each release
• Use password managers that match credentials to exact domains, catching homograph fakes automatically

6. Emoji Domains

Since emojis are Unicode characters, Punycode can encode them as domain names. The coffee cup emoji becomes xn--53h.com. The pizza slice emoji becomes a different xn-- string. Technically functional, but practically limited: most registrars restrict emoji registrations, many browsers display the Punycode form instead of the emoji, and linking to an emoji domain from most platforms is unreliable.

The deeper problem: emoji rendering varies by OS, browser, and font. A domain that shows a clear coffee cup on iOS might show a different glyph on Android or render as a missing-character box on older systems. This makes emoji domains a poor choice for anything requiring reliable recognition.

7. Punycode and the Broader Encoding Landscape

Punycode is a specialized encoding for one purpose: fitting Unicode into DNS labels. It is not a general-purpose character encoding like UTF-8 or ISO 8859-1. You would never encode a web page or a database field in Punycode. Its value is precisely its narrow scope: it makes the 40-year-old DNS infrastructure support modern multilingual domain names without replacing any existing DNS software.

For a broader perspective on how character encodings work together, see the character sets reference. For the history of how we got from ASCII-only to a multilingual internet, read the evolution of character encoding. And to explore ASCII's foundational role, browse the full ASCII table or check the glossary for terms like Unicode, UTF-8, and code point.