Punycode converter

What is punycode?

Domain names on the wire may only contain letters a to z, digits and hyphens. Punycode, defined in RFC 3492, is how a domain written in any other script gets squeezed into that alphabet: münchen.de becomes xn--mnchen-3ya.de, and пример.рф becomes xn--e1afmkfd.xn--p1ai. The xn-- prefix marks a label that has been encoded this way, and everything after it is the punycode itself.

It is a clever piece of engineering. The ASCII characters are copied out first, then a compact series of base-36 digits describes which non-ASCII characters to insert and where. Nothing is lost, the encoding is reversible, and short names stay short.

You mostly meet it in two situations. Either a browser has shown you a link as xn--80ak6aa92e.com and you want to know what it actually says, or you have a domain in your own script and need the ASCII form for a config file, a certificate or a DNS record. This tool does both, entirely in your browser.

How to use it

1. Choose the direction you need. Punycode to Unicode turns an xn-- domain back into letters. Unicode to Punycode goes the other way, for when you need the ASCII form.
2. Paste the domain in. Whole domains work, not just single labels — each part between the dots is converted separately, exactly as DNS treats it.
3. Read the label breakdown and the script list. Every label is shown with its result, so you can see which part carried the encoding. The writing systems used are listed underneath, with a warning if any single label mixes more than one.

The browser does one direction and refuses the other

This is worth knowing, because it explains why tools like this exist at all. Every browser contains a complete punycode implementation, and you can reach part of it from JavaScript: constructing a URL from münchen.de gives back a hostname of xn--mnchen-3ya.de. The encoding direction is free.

The reverse is not available. Hand the same parser xn--mnchen-3ya.de and it returns it unchanged — which is correct behaviour, because that is already a valid hostname and there is no reason to touch it, but it means the platform will not tell you what an encoded domain says. That is exactly the direction a person needs when they are looking at a suspicious link, so it has to be implemented rather than borrowed. This page implements RFC 3492 in full, checked against all nineteen of the test vectors the specification publishes.

Two names that look the same and are not

The reason punycode matters beyond curiosity is that it is how a lookalike domain gets registered. A Latin a and a Cyrillic а are different characters that most fonts draw identically. Type apple.com with the Cyrillic one and it encodes to xn--pple-43d.com — a completely different domain that renders, in a browser's address bar, as something very close to the real thing.

The check browsers make is whether a single label mixes writing systems, and this tool shows you the same thing. A name with one Cyrillic letter among Latin ones is flagged. But the check has a hole worth understanding: a label written entirely in Cyrillic lookalikes is consistent single-script text, so it passes. Several Cyrillic letters are close enough to Latin ones that whole words can be spelled that way. The mixed-script warning is a useful signal and not a guarantee, and this page says so rather than implying the absence of a warning means safety.

There are two further surprises in the encoding itself. The German ß is one of a small set of characters whose meaning changed between the two versions of the IDNA standard: under the older rules faß.de was mapped to fass.de and they were the same domain, while under the current rules faß.de encodes to xn--fa-hia.de and they are two different registrations. And in Greek, uppercasing a domain and lowercasing it back does not return the domain you started with, because a final Σ lowercases to ς rather than σ — so ΣΊΣΥΦΟΣ.gr and σίσυφος.gr are not the same name.

Honest limits

This converts punycode; it does not tell you whether a domain is dangerous. A name can be perfectly ordinary in its own script and a name can be pure ASCII and still be a phishing site. What the tool gives you is the letters and the writing systems, which is information a browser's address bar does not show you and which is genuinely useful — but the judgement is yours.

The script detection is deliberately coarse. It covers Latin, Greek, Cyrillic, Han, Arabic and Hebrew, which are the ranges that matter for the confusion this page is about, and everything else is labelled Other rather than guessed at. Digits, hyphens and punctuation are counted as Common and never make a domain look mixed on their own.

There is also a layer above punycode that this tool does not enforce. IDNA2008 has rules about which characters may appear in a domain at all, and browsers apply their own additional restrictions — most registries will not sell you a mixed-script name in the first place. So a domain this page converts happily may still be one no registrar would accept. Conversely, a browser will encode things the standard forbids: an emoji domain converts here and in your browser, and a leading or trailing hyphen passes, though neither is valid under a strict reading.

Finally, decoding is done on the label alone. If a name is not marked with the xn-- prefix, it is passed through untouched, because there is no way to tell an unmarked punycode string from an ordinary word that happens to look like one.

Why is it free?

Because it costs nothing to run. The conversion happens in your browser as you type; nothing is uploaded, nothing is logged, and no server sees the domains you paste — which matters more than usual here, since the whole reason to use this page may be that you do not trust the link you were sent.

No account, no sign-up, nothing held back. The algorithm is RFC 3492 as published, verified against all nineteen of the specification's own test vectors and against a separate reference implementation.