Punycode Converter — Punycode ↔ Unicode Domain Names
Convert an internationalised domain name between Unicode and the ASCII punycode the DNS carries — münchen.de ↔ xn--mnchen-3ya.de — and see exactly what each label becomes.
—
What this tool does
It converts an internationalised domain name between the Unicode form people type and the ASCII
form the DNS actually carries. Each label is handled separately, so you can see which label becomes
xn--… and which is left alone, and a non-ASCII label that is already encoded is never
encoded a second time.
The two forms, side by side
| Unicode | Punycode (ASCII) |
|---|---|
| münchen.de | xn--mnchen-3ya.de |
| bücher.example | xn--bcher-kva.example |
| 例え.テスト | xn--r8jz45g.xn--zckzah |
| example.com | example.com |
An all-ASCII label has nothing to encode, so it passes through unchanged — ASCII is already its own
punycode form. That is why only the labels that need it gain an xn-- prefix, and why a
domain can be mixed: xn--mnchen-3ya.example is perfectly ordinary.
What the encoding actually does
Punycode is a bootstring: it copies the ASCII characters of a label straight through, then encodes
the position and value of every other character as a run of base-36 digits after a delimiter. The
digits are ordered so that common scripts compress well, which is why münchen — one
non-ASCII letter — costs only a few characters while a label of pure Han gains more. The algorithm
is defined in RFC 3492 and this tool implements it directly rather than delegating to the browser.
Where you meet punycode in practice
Seeing an xn-- name is usually a sign you are looking at the wire form rather than the
display form: a certificate's subject, a mail log, an analytics report or a DNS record. It also
matters when you compare names for equality — two strings that look the same can encode differently
if one has not been normalised, and names that look different can decode to the same thing, which is
the homograph problem. Checking the decoded form is the practical defence.
Frequently asked questions
What is punycode?
Punycode is the encoding (RFC 3492) that lets an internationalised domain name be sent over the DNS, which only carries ASCII. A label such as münchen is encoded to mnchen-3ya, prefixed with xn--, and used as xn--mnchen-3ya.de. The Unicode name stays what people type and see; punycode is what the network carries.
Why does a domain show up as xn--?
Because you are seeing the wire form rather than the display form. Some places — a TLS certificate detail, an analytics report, a log line — show the ASCII encoding instead of decoding it back. The two are the same name; this tool converts either way so you can confirm that.
What is the difference between punycode and IDNA?
Punycode is the encoding itself; IDNA is the set of rules that say how a name is prepared before encoding — case folding, normalisation, which characters are allowed. This tool implements punycode (RFC 3492) and does the light normalisation (NFC, lower-cased ASCII) that keeps a name stable, so its output matches what a browser produces.
Is a domain with xn-- safe?
xn-- is not a sign of anything bad — every internationalised domain uses it, including well-known ones. It is, however, the mechanism behind homograph attacks, where a lookalike character is used to imitate a brand. Check the decoded form: if a name that looks like a familiar one decodes to unexpected characters, be suspicious.
Why not just use the browser URL API?
Because it only exposes the ASCII form when you build a whole URL, and it will not decode one back to Unicode for you. Domain work needs the label-by-label conversion in both directions, which is what this implements — and it handles non-BMP characters such as mathematical letters that older punycode implementations get wrong.
Is anything sent anywhere?
No. The encoding is arithmetic on the text you type, done in your browser. No name is resolved, looked up or sent to a server.
Go deeper
Longer explanations of the problems this tool solves:
Sources
- RFC 3492 — Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications.
- RFC 5890 — Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework.
- IDNA Parameters — the IANA registry of properties and the ACE prefix (xn--).
Everything runs in your browser — nothing you type is uploaded.