Punycode Converter
Convert domains between Unicode and Punycode — encode an internationalised (IDN) domain to its ASCII xn-- form, or decode a xn-- domain back to Unicode. It converts each label on its own and flags IDN homograph risk — the look-alike characters used to spoof domains in phishing. Everything runs in your browser; nothing is uploaded.
Everything runs locally in your browser — the domain you paste is never uploaded or sent to any server. Safe for inspecting a suspicious link from a phishing email offline.
What this tool is
- A free, in-browser Punycode converter: encode a Unicode domain to its ASCII xn-- form (Unicode → Punycode) and decode xn-- domains back to Unicode (Punycode → Unicode).
- Works per label: each dot-separated part is converted on its own, so only the labels that actually need it get the xn-- prefix and plain-ASCII labels pass through unchanged — e.g. 例え.jp → xn--r8jz45g.jp.
- Built for the security use case: it flags IDN homograph risk when a domain mixes scripts or uses look-alike characters (a Cyrillic "а" posing as a Latin "a"), the trick behind spoofed phishing links.
- Implements the standard RFC 3492 Bootstring algorithm, so conversions round-trip exactly (münchen ⇄ xn--mnchen-3ya, bücher ⇄ xn--bcher-kva).
- Everything runs client-side. The domain you paste — including a suspicious link from a phishing email — is never uploaded or sent to a server.
What is Punycode and IDNA?
Punycode (RFC 3492) encodes arbitrary Unicode text into the narrow set of characters the Domain Name System permits — the letters a-z, the digits 0-9 and the hyphen. It is the encoding half of IDNA (Internationalizing Domain Names in Applications), the standard that lets a domain contain accented letters, Chinese characters or other non-ASCII text. A Punycode label carries the prefix xn--, so the Unicode domain münchen.de travels through DNS as xn--mnchen-3ya.de.
Why it is per label
A domain is a series of dot-separated labels, and each is converted on its own. Only labels that actually contain non-ASCII characters are encoded and prefixed with xn--; ordinary ASCII labels pass through untouched. In xn--r8jz45g.jp (from 例え.jp) only the first label was internationalised — the .jp is already ASCII, so it is left exactly as it is.
The xn-- form you meet in the wild
The Unicode name is what a person types and sees in the address bar; the xn-- form is what actually appears in DNS queries, TLS certificate subject names, email headers, proxy logs and SIEM events. When you are reading raw telemetry rather than a rendered page, Punycode is usually all you get — decoding it back to Unicode is how you find out what the domain really says.
The security angle: IDN homograph attacks
Internationalised domains created a phishing technique: the IDN homograph attack. Many Unicode characters are visually identical to ASCII letters — the Cyrillic а (U+0430) is indistinguishable on screen from the Latin a. An attacker registers a look-alike such as аpple.com (with a Cyrillic first letter). It reads as the real brand, but it is a different domain pointing at the attacker's server. Decode it and the disguise falls away: аpple.com is really xn--pple-43d.com — plainly not apple.com.
- Decode before you trust. Paste any
xn--link from an email or log and read the Unicode it expands to — the real domain, not the one that was shown to you. - Watch for mixed scripts. A genuine IDN is almost always written in a single script. A label that mixes Latin with one stray Cyrillic or Greek character is a classic spoof — this tool flags it.
- Do not rely on your eyes. Confusable characters exist precisely because they defeat visual inspection. The Punycode form, not the rendered text, is the ground truth.
Security note: This converter runs entirely in your browser — the domain you paste is never transmitted — so it is safe to inspect a suspicious link from a phishing email offline. The homograph warning is a heuristic aid, not a verdict: a clean result does not prove a domain is safe, and a flagged domain may still be a legitimate internationalised name. Always confirm a destination through a trusted channel before acting on it.

Frequently asked questions
What is Punycode?
Punycode is a way of representing Unicode text using only the limited ASCII characters that the Domain Name System allows (letters a-z, digits 0-9 and the hyphen). It is defined by RFC 3492 and is the encoding half of IDNA, the standard that lets domain names contain non-ASCII characters such as accented letters, Chinese characters or emoji. A Punycode label is marked with the prefix "xn--"; for example the Unicode domain münchen.de is transmitted on the wire as xn--mnchen-3ya.de. Browsers encode an internationalised domain to Punycode before the DNS lookup and decode it back for display.
What does the xn-- prefix mean?
The "xn--" prefix (the ACE, or ASCII-Compatible Encoding, prefix) tells software that the rest of the label is a Punycode-encoded Unicode string rather than an ordinary ASCII label. Everything before the final hyphen in the encoded part is the basic ASCII characters of the original label, kept as-is; everything after it is the compressed encoding of the non-ASCII characters and where they belong. A label with no non-ASCII characters is left completely alone — it never gets an xn-- prefix. That is why this tool converts each label independently: in xn--mnchen-3ya.de only the first label was internationalised, so only it is encoded while .de passes through.
Why does Punycode exist?
DNS was designed when host names were limited to ASCII letters, digits and hyphens, but the world writes domains in many scripts. Punycode and IDNA bridge that gap: they let someone register and use a domain in their own language (for example café.fr or 例え.jp) while the underlying DNS still only ever sees ASCII. The Unicode name is what a person types and sees; the xn-- form is what actually travels through DNS resolvers, TLS certificates and logs. Converting between the two is essential when you are reading raw logs, certificate subject names or email headers, where only the xn-- form appears.
What is an IDN homograph attack?
An IDN homograph (or homoglyph) attack abuses the fact that different Unicode characters can look identical on screen. An attacker registers a domain that visually matches a trusted brand but uses look-alike characters from another script — for instance replacing the Latin "a" in apple.com with the Cyrillic "а" (U+0430). To the eye the two addresses are indistinguishable, but they are different domains that resolve to different servers, so a victim who clicks the link lands on the attacker. Decoding the domain to its Punycode form is the reliable defence: the spoofed address reveals itself as something like xn--pple-43d.com, which obviously is not the real apple.com.
How do I tell a real domain from a homograph spoof?
Convert it to Punycode and read the xn-- result, and watch for a domain that mixes scripts. A genuine internationalised domain is usually written entirely in one script (all Latin, all Cyrillic, all Han); a label that mixes, say, Latin letters with a single Cyrillic or Greek character is a strong signal of a spoof. This tool highlights both: it decodes any xn-- domain so you can see what it really is, and it warns when the Unicode form mixes scripts or contains characters that imitate ASCII letters. Modern browsers also defend against this by displaying the raw Punycode in the address bar when a domain looks suspicious, but you should never rely on visual inspection of a link alone.