Punycode Converter

Convert internationalized domains to and from Punycode.

Unicode Domain

xn--mnchen-3ya.de

Internationalized Domain Names & Punycode

DNS only allows a limited set of ASCII characters, but domain names can contain Unicode (e.g. münchen.de). Punycode is the encoding (RFC 3492) that represents such names using only ASCII, prefixed with xn--. This converter encodes Unicode domains to their xn-- form and decodes them back — per label, preserving the dots — entirely in your browser.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Checking what an `xn--` domain in a phishing report actually spells before clicking anything.
Registering an internationalised domain and needing the ASCII form the registrar and DNS will store.
Working out why a TLS certificate appears not to match a domain that looks correct in the address bar.
Comparing two visually identical domains to see whether they are in fact different registrations.
Putting a non-ASCII hostname into a config file whose parser only accepts ASCII.

Frequently Asked Questions

What is Punycode for?: Encoding internationalised domain names into the ASCII subset DNS actually permits. münchen.de becomes xn--mnchen-3ya.de — the xn-- prefix marks an encoded label, and the suffix after it restores the non-ASCII characters.
How does the encoding work?: It is not a per-character substitution. ASCII characters are kept in order, then the non-ASCII ones are appended as a compressed series of insertion positions and code points, using a bootstring algorithm defined in RFC 3492.
What is a homograph attack?: Registering a domain using look-alike characters from another script — Cyrillic а renders identically to Latin a, so аpple.com can be visually indistinguishable from apple.com. Punycode decoding is how you tell them apart.
Why do browsers sometimes show the xn-- form?: As a defence against exactly that attack. Browsers display Unicode only when the label's script matches the user's languages or the TLD's policy; a mixed-script label falls back to raw Punycode, which looks alarming and is meant to.
Does it apply to the whole domain?: No — each dot-separated LABEL is encoded independently, and only labels containing non-ASCII get the xn-- prefix. It also does not apply to the path, query or email local part, which use percent-encoding or SMTPUTF8 instead.
What is IDNA and how does it relate?: IDNA is the wider standard; Punycode is only its encoding step. Before encoding, IDNA normalises and validates the label — case folding, disallowing certain characters, and applying script rules. Punycode alone will happily encode a name IDNA would reject.
Why is there a 63-character limit per label?: Because DNS itself imposes it, and the limit applies to the ENCODED form. A Unicode label that looks short can exceed 63 characters after encoding, which is why some otherwise valid names cannot be registered.
Do email addresses use Punycode?: The domain part can, but the local part is a separate standard — SMTPUTF8 — which sends UTF-8 directly rather than encoding it. So an internationalised address is not simply Punycode applied on both sides of the @.

Common errors and gotchas

Encoding the entire domain in one pass. Each label is encoded separately, so `xn--` appears per label and never spans a dot.
Adding the `xn--` prefix by hand to a label that is already pure ASCII. Such labels are left alone, and prefixing one makes it invalid.
Assuming visual similarity means equality. Two labels that render identically can encode to completely different ASCII.
Overlooking the 63-character limit per label, which the encoded form can exceed even when the original does not.
Expecting case to survive. The process normalises case, so the decoded label will not necessarily match what you typed.