Guide
Punycode and internationalised domain names
The Domain Name System was built for letters, digits and hyphens. To let people register names in their own scripts, the standards bodies chose an encoding that turns any Unicode label into an ASCII one, and Punycode is that encoding. A domain like münchen.de is stored and looked up as xn–mnchen-3ya.de, and your browser converts it for display. This page shows both forms and converts either way.
How Punycode works
The algorithm, defined in RFC 3492, keeps the ASCII characters of a label as they are and writes them first, followed by a hyphen. It then appends a compact description of where each non-ASCII character goes and which character it is, using variable-length numbers in base 36. For münchen, the ASCII letters mnchen come first, then a hyphen, and the ü is described by the trailing 3ya. A label with only ASCII needs no conversion.
The xn– prefix
To tell a Punycode label from an ordinary one, domain names add the prefix xn– in front of the encoded text. So the label münchen becomes xn–mnchen-3ya. The prefix applies to each label separately: the Russian name пример.рф is xn–e1afmkfd.xn–p1ai, with both labels converted, while a domain such as bücher.example gives xn–bcher-kva.example because only the first label has non-ASCII characters.
Using the page
Paste domain names, one per line. The page detects the direction for each line: if any label begins with xn– it is decoded, and otherwise it is encoded. The results appear on the right in the same order. A second mode treats each line as a single string and converts it without the prefix, which is useful for inspecting the raw algorithm output. Errors, such as a malformed Punycode digit, are reported next to the line they belong to.
Normalisation and case
Before encoding, text is lower-cased and put into Unicode normalisation form NFC, so that a letter written as a base plus a combining mark and the same letter written as one character give the same result. Without this step, visually identical names could produce different Punycode. The page does not apply every mapping rule of UTS 46, such as the special treatment of the German ß or of joiner characters, so unusual names may differ from what a particular registry or browser produces.
Look-alike names
Because many letters of different alphabets look alike, an attacker can register a name that reads as a well-known site. When a single label of a name mixes writing systems, a warning appears. A fully Cyrillic name that looks like a Latin one will not trigger it, so treat the warning as a hint and not a guarantee. If you receive a link you do not trust, converting its host to Punycode shows exactly which characters it contains.
A worked example
The Sample button converts a list. münchen.de gives xn–mnchen-3ya.de, bücher.example gives xn–bcher-kva.example, 日本語.jp gives xn–wgv71a119e.jp and пример.рф gives xn–e1afmkfd.xn–p1ai. The line xn–fsq.jp goes the other way and shows 例.jp. None of these mixes writing systems inside one label, so no warning appears; a label that combined a Latin a with a Cyrillic а would trigger it.
Limits
The converter implements Punycode and the basic preparation steps. It does not check names against the IDNA 2008 tables, registry policies or the public suffix list, and it does not look names up. Whether a domain can be registered or resolved is outside its scope.
Related tools
- URL Encoder percent-encodes the rest of an address.
- Unicode Inspector lists the code points and scripts in a suspicious name.
- HTML Encoder writes non-ASCII characters as entities for web pages.
- UTF-8 Byte Counter shows how many bytes a name takes.
Checked against the current version of the Punycode Converter on .

