Punycode converter

Convert internationalized domains to/from Punycode (xn--).

Converts non-ASCII domains (Korean, emoji, etc.) into the ASCII (xn--) form used by browsers and DNS. Each dot-separated label is processed individually.

You register a domain with non-English characters in it, and then find it showing up in your certificate details, your DNS panel and your server logs as something like xn--bj0bj06e.com. It looks like garbage, but it is the same name.

DNS only understands a narrow set of ASCII characters, so any domain containing other characters is translated into an ASCII form before it travels the network. This tool converts in both directions: paste a Unicode domain to see its xn-- form, or paste an xn-- string to see what it really says.

How it works

The two buttons

Type a domain or a text label into the input box, then choose a direction. Unicode -> Punycode produces the ASCII form; Punycode -> Unicode reads an xn-- string back into readable characters. Copy puts the result on your clipboard.

How the encoding works

Punycode separates a label into two parts. The ASCII characters that were already allowed are kept in their original order, and everything else is encoded as a compact sequence of ASCII characters describing which non-ASCII characters go where. The whole label then gets the prefix xn-- so software knows the rest needs decoding.

The conversion is done label by label - that is, per dot-separated section - not on the whole string at once:

Original	Encoded
`shop.example.com` (all ASCII)	unchanged; nothing to encode
a Unicode label + `.com`	`xn--<encoded>.com` - only the first label changes
Unicode in two labels	each label gets its own `xn--` prefix

This is why a mixed domain often comes back with the recognisable parts still readable. Only the labels that actually contain non-ASCII characters are touched.

Things to watch for

The encoding is exact and reversible, so a round trip should return precisely what you started with. If it does not, the input usually contains an invisible or lookalike character - a zero-width space, a non-breaking space, or a Cyrillic letter that resembles a Latin one.

That last point matters for more than tidiness. Because different scripts contain visually similar characters, a domain can be crafted to look like a familiar brand while resolving somewhere else entirely - the so-called homograph problem. Modern browsers defend against this by displaying the raw xn-- form instead of the pretty version when a name mixes scripts suspiciously. If a link looks normal but the address bar shows xn--, decoding it here is a quick way to see what the name actually contains before you trust it.

Terms explained

Punycode: An encoding that represents Unicode characters using only the ASCII letters, digits and hyphen that DNS permits. Defined in RFC 3492.
IDN (Internationalised Domain Name): A domain name containing characters outside basic ASCII - Korean, Arabic, accented Latin letters and so on.
xn-- prefix: The ACE prefix marking a label as Punycode-encoded. Software that sees it knows the rest of the label must be decoded before display.
Label: One dot-separated section of a domain name. In shop.example.com there are three labels, and each is encoded independently.
ACE (ASCII Compatible Encoding): The general term for representing a non-ASCII label in pure ASCII so that existing DNS infrastructure can carry it unchanged.
Homograph attack: Registering a domain using characters that look like those of a well-known name in order to deceive readers. Decoding the xn-- form reveals the real characters.

Frequently asked questions

Why does my domain appear as xn-- in some places but normally in others?

They are the same name in two forms. DNS, TLS certificates and most server logs work with the ASCII xn-- form, while browsers decode it and show the readable version in the address bar when it is safe to do so. Nothing has gone wrong - you are just seeing different layers of the same lookup.

Does converting a domain to Punycode change where it points?

No. Punycode is a lossless encoding, not a redirect or an alias, so the Unicode form and its xn-- form are two spellings of one identical name. Whatever DNS records exist for the domain apply the same way regardless of which form you type.

Why did only part of my domain change?

Because each dot-separated label is encoded on its own, and a label containing nothing but ASCII needs no encoding at all. So a Unicode second-level name followed by .com yields an xn-- first label with the .com left exactly as it was.

My decoded result does not match what I expected. What went wrong?

Usually the input contains a character you cannot see - a zero-width space, a non-breaking space, or a character from another script that closely resembles a Latin letter. Retyping the domain by hand rather than pasting it, then converting again, normally isolates the problem.

Why do browsers sometimes refuse to display the readable form?

As a safety measure against lookalike domains. When a name mixes scripts in a way that could be used to imitate a familiar brand, the browser shows the raw xn-- text so the deception is visible. Decoding that string reveals which characters the name actually uses.