Punycode to Unicode

Punycode to Unicode

Paste a domain, URL or email address containing xn-- into Input, and the readable form appears under Unicode as you type. There are two modes:

• Domain names, URLs and email addresses (xn-- labels decoded one by one). This is the usual choice. In a whole URL or email address, only the domain changes. The path, the query and the part before the @ stay exactly as typed.
• Any raw Punycode string (RFC 3492, no xn-- prefix). This is for a bare Punycode string, such as you’d find in code or a specification.

You can paste several names at once, one per line. A summary counts the names and labels. Each label gets a row showing its decoded form, whether it was decoded or kept, and which scripts its letters come from. Labels are checked the way a browser checks them, and look-alike letters are flagged before you trust a link.

Example, Clear and Copy do what you’d expect. Everything runs in your browser.

Example

The Example button loads five names:

The summary reads 5 names, 10 labels: 6 decoded, 4 kept as they are. The four kept are example, de, com and jp, which were never Punycode.

Two of the names mean “example”. пример.рф is Russian, under Russia’s own Cyrillic domain ending .рф, and 例え.jp is Japanese. The third line is the one to watch. It’s covered under “Look-alike domains” below.

What Punycode is

The DNS system that turns domain names into addresses only understands plain letters, digits and hyphens. Domains can still contain ü, Cyrillic, Chinese characters or emoji: each such label is converted to Punycode and marked with the prefix xn--. Browsers, mail servers and DNS see xn--mnchen-3ya.de, while people see münchen.de.

The encoding is clever rather than secret. In mnchen-3ya, the plain letters come first (m-n-c-h-e-n), then a hyphen. After that comes a short code (3ya) that says which character to insert where: ü, after the m. That’s why Punycode versions of mostly-Latin names still look a little like the original. Names in other scripts, like e1afmkfd for пример, have no plain letters to keep, so they’re all code.

Label by label

A domain is made of labels separated by dots, and each one is handled on its own. A label starting with xn-- is decoded. Any other label is only lower-cased. In a URL or email address, everything except the domain stays exactly as typed.

Every label gets a row showing what it became, whether it was decoded or kept, and the scripts its letters come from:

• “Latin” for münchen
• “Cyrillic” for пример and рф
• “Hiragana + Han” for 例え, which mixes Japanese syllables with Chinese characters, as Japanese normally does

Labels are checked the way a browser checks them, and flagged when browsers would refuse them:

• Broken Punycode that can’t be decoded at all.
• A form IDNA would never produce, such as a label that decodes to upper-case letters. Real encoders always lower-case first, so such a label was made by hand.
• Plain ASCII. A label that starts with xn-- but decodes to ordinary letters only shouldn’t exist, because plain letters never need Punycode.

Look-alike domains

Some letters in other alphabets look identical to Latin ones. Cyrillic а, р and е are indistinguishable from Latin a, p and e in most fonts. That makes it possible to register a domain that looks like a famous one but belongs to someone else. The third name in the example is exactly that:

xn--80ak6aa92e.com   →   аррӏе.com

Its row reads: “Scripts: Cyrillic. Every non-Latin letter here is a look-alike of a Latin letter (Cyrillic or Greek); this is the classic homograph attack.”

That isn’t apple.com. Every letter is Cyrillic: а, two р, the letter palochka (ӏ, standing in for l), and е. In 2017 a researcher registered exactly this domain to show that browsers displayed it as “apple.com” in the address bar.

Names that mix Latin with Cyrillic or Greek letters are highlighted the same way, because mixing is the other common trick. One swapped letter in an otherwise Latin name is enough.

Most browsers now show such labels as xn-- in the address bar for this reason. But not every app does: email clients, chat apps and documents may show the Unicode form. For a closer check of a suspicious link, use the IDN/Punycode Phishing Detector.

Raw Punycode

Punycode itself, defined in RFC 3492, is just a way to write Unicode text in plain letters. The xn-- prefix is what domain names add on top. In raw mode, paste a string without the prefix, such as mnchen-3ya, and you get münchen. That’s useful when working with libraries, specifications or test data that use the bare encoding.

Where you’ll meet xn--

• Server logs and analytics, which often record international domains in their xn-- form.
• SSL certificates, which list international domain names in Punycode.
• DNS records and registrar panels. Some show only the encoded form. DNS Lookup and Hostname to IP accept either.
• Email headers, where sender domains appear encoded.
• The address bar, when your browser decides a domain looks suspicious and shows xn-- instead.

FAQ

Why does my browser show xn-- instead of the name?

Browsers show the Unicode form only when they consider it safe. If a label mixes alphabets, or is made of letters that imitate Latin ones, they show xn-- to warn you. Seeing it isn’t proof of a scam, but it’s a reason to look twice.

Is a Punycode domain dangerous?

Usually not. Millions of legitimate domains are written in Chinese, Arabic, Cyrillic, Greek, Japanese, or Latin letters with accents, and all of them travel as xn--. Only domains built to imitate another name are a problem, and those are what the look-alike check flags.

How do I convert a name to xn--?

Use Unicode to Punycode. It applies the same rules browsers use, including lower-casing and mapping of full-width characters.

Can I decode Punycode in code?

In Python, 'xn--mnchen-3ya.de'.encode().decode('idna') gives münchen.de. Most languages have an IDNA library that does the same.