Punycode Decoder

About Punycode

A domain name can be written in any script, but the systems that carry it — DNS, certificates, mail headers — only move ASCII. Punycode is the bridge: münchen.de travels as xn--mnchen-3ya.de, and the xn-- prefix is what marks a label as encoded rather than as a name that happens to start with those letters.

The conversion is per label, not per name, which is why a result here is a list. bücher.example.com becomes xn--bcher-kva.example.com — one label changed, two were already ASCII and were left exactly as they were. That matters when you are comparing what a registrar shows against what a certificate contains, because the difference is usually in one label rather than across the whole name.

Where it helps

• Works label by label, so a name says which part of it changed.
• Encoding leaves ASCII labels untouched rather than rewriting a name that was already correct.
• Decoding is the direction browsers do not offer: they will encode a name for you, but never show you what an xn-- label says.
• Implements RFC 3492 directly, so the output matches what DNS and certificate tooling produce.

Limits

• This is the encoding step only, not the whole of IDNA: it does not apply the normalisation, case folding or character restrictions a registry applies before a name is allowed.
• It will happily encode a label that no registry would accept, because whether a name is permitted is a policy question rather than an encoding one.
• Decoding cannot tell you whether a name is a homograph of another one. It shows you the characters; judging whether аpple and apple differ is left to you — and worth doing, because that is what the attack relies on.

Frequently asked questions

What does the xn-- prefix mean?

It marks a label as holding punycode rather than plain text. It is IDNA's marker, not punycode's, which is why encoding a single label here adds it and decoding strips it.

Why did only part of my domain change?

Because only the labels that contain non-ASCII characters need encoding. A label that is already ASCII is correct as it stands and is passed through untouched.

My browser shows the readable name but the certificate shows xn--. Which is right?

Both. The certificate carries the ASCII form because that is what the protocol moves; the browser decodes it for display. This tool does the same decoding by hand.

Can I paste a whole URL?

Paste the host part. This converts domain labels, so a scheme and a path would be treated as labels and encoded along with everything else.

Related tools

• URL Encoder — Percent-encode components or whole URLs
• Unicode Converter — Escape, unescape and inspect code points
• DNS Lookup — Resolve A, AAAA, MX, TXT, NS, CNAME, SOA and CAA records
• SSL Checker — Grade a TLS endpoint and inspect the certificate it serves
• Base64 — Encode or decode UTF-8 text and URL-safe Base64
• Base32 — Encode or decode Base32 in the RFC 4648, extended hex and Crockford alphabets

More Encoders & Decoders tools

• Base64 — Encode or decode UTF-8 text and URL-safe Base64
• Base32 — Encode or decode Base32 in the RFC 4648, extended hex and Crockford alphabets
• Base58 — Encode or decode Base58, and verify the Base58Check checksum an address carries
• URL Encoder — Percent-encode components or whole URLs
• HTML Entities — Escape and unescape HTML entities
• JWT — Read, verify and sign JSON Web Tokens
• Punycode — Convert internationalised domain names to and from their ASCII form
• Unicode Converter — Escape, unescape and inspect code points
• Unicode Inspector — Analyse every character: category, script, block and encoding
• Number Base Converter — Binary, octal, decimal and hexadecimal, with the bits explained
• Hex and Text Converter — Text to hexadecimal bytes and back, with a dump
• Gzip Compressor and Decompressor — Compress and expand gzip, zlib and raw deflate