🍱 Lunchbox Hands

Punycode Converter

Convert IDN domains to Punycode (xn--) and back, with homograph warnings

Paste any internationalized domain — münchen.de, 日本.jp, an email address, or a whole list — and get the ASCII xn-- form that DNS actually carries, broken down label by label. Paste an xn-- domain and it decodes back to Unicode instead; the direction is detected automatically. Every label is checked for the things that bite in practice: the 63-octet label and 253-octet domain limits, empty labels, illegal hyphen positions, invisible characters, and homograph risk — a label mixing Cyrillic with Latin, like аpple.com, is flagged with the exact confusable code points. Each result is also cross-checked against your browser's own URL parser so you can see what would really go on the wire. Everything runs locally. Once you know the real hostname, look up who owns it with the WHOIS Lookup or check its records with DNS Lookup. For picking apart a full URL rather than a hostname, use the URL Parser, and to inspect suspicious characters one by one see the Unicode Inspector, the Invisible Character tool, or our writeup on invisible Unicode characters.

Direction
Samples
münchen.de
xn--mnchen-3ya.de
encoded · ok
LabelResultBytesType
münchenxn--mnchen-3ya14ACE (xn--)
dede2unchanged
DNS (ASCII) form: xn--mnchen-3ya.deYour browser would send: xn--mnchen-3ya.de
日本.jp
xn--wgv71a.jp
encoded · ok
LabelResultBytesType
日本xn--wgv71a10ACE (xn--)
jpjp2unchanged
DNS (ASCII) form: xn--wgv71a.jpYour browser would send: xn--wgv71a.jp
аpple.com
xn--pple-43d.com
encoded · check
LabelResultBytesType
аpplexn--pple-43d12ACE (xn--)
comcom3unchanged
DNS (ASCII) form: xn--pple-43d.comYour browser would send: xn--pple-43d.com
  • Warning: Label "аpple" mixes Cyrillic + Latin in a single label. Suspicious characters: "а" (U+0430, Cyrillic). Chrome and Firefox refuse to display labels like this as Unicode and show the raw xn-- form instead.
xn--mnchen-3ya.de
münchen.de
decoded · ok
LabelResultBytesType
xn--mnchen-3yamünchen14ACE (xn--)
dede2unchanged
DNS (ASCII) form: xn--mnchen-3ya.deYour browser would send: xn--mnchen-3ya.de

Frequently asked questions

What is Punycode and what does xn-- mean?

DNS only carries the ASCII letters, digits and hyphen. Punycode (RFC 3492) is the algorithm that squeezes a Unicode domain label into that alphabet, and IDNA marks the result with the prefix xn-- so resolvers know to decode it. So "münchen.de" travels the network as "xn--mnchen-3ya.de" and "日本.jp" as "xn--wgv71a.jp". Each dot-separated label is encoded on its own — that is why the .de and .jp parts stay readable.

What is the homograph warning telling me?

Two different checks from Unicode UTS #39. Mixed-script flags a single label that combines two or more scripts, such as "аpple.com" where the first letter is Cyrillic а (U+0430) and the rest is Latin — it encodes to xn--pple-43d.com and looks identical to apple.com in most fonts. Whole-script confusable flags a label that is entirely one non-Latin script but spelled with characters that are Latin lookalikes, like Chromium’s example аррӏе.com, which mixed-script checks miss because it never mixes. Chrome and Firefox apply similar rules and refuse to render such labels as Unicode, showing the raw xn-- form in the address bar instead. The tool lists each suspicious character with its code point so you can see exactly which one is doing the impersonating.

Is this full IDNA2008 / UTS #46 processing?

No, and that matters. The engine is the punycode npm package, which implements RFC 3492 plus the older IDNA2003-style ToASCII/ToUnicode wrappers. It does not do UTS #46 mapping: no Unicode case folding beyond ASCII, no deviation-character decisions (German ß is left alone rather than mapped to ss, final sigma ς is not folded to σ), and no IDNA2008 validity, bidi or contextual-rule checks. This tool adds NFC normalization and ASCII lowercasing itself, and then cross-checks every domain against your browser’s own URL parser, which does implement UTS #46. That is the "Your browser would send" line under each result; when the two disagree you get a warning and both values, and the browser value is the one that actually goes on the wire.

Why does encoding a plain ASCII word add a trailing hyphen?

That is the Raw Punycode tab, and it is correct. RFC 3492 separates the literal ASCII part of a string from the encoded part with a hyphen delimiter, so "plain" encodes to "plain-". In real domain names this never appears on its own, because a label that is already pure ASCII is left alone and never gets an xn-- prefix at all. The Domains tab does that for you.

Can I convert email addresses and lists of domains?

Yes. Paste an address like anna@münchen.de and only the domain after the last @ is converted — Punycode does not apply to the local part, which needs SMTPUTF8 (RFC 6531) support on both mail servers instead, and the tool notes that when your local part is non-ASCII. For bulk work, put one domain per line and each gets its own result card, warnings and label breakdown.

Does anything I paste leave my browser?

No. The conversion, the validation and the homograph analysis all run locally in JavaScript, and the browser cross-check uses the URL parser already built into your browser. There are no network requests, no uploads and no signup. If you want live DNS or registration data for a domain, that needs a lookup — use the DNS Lookup or WHOIS tools.

Get weekly dev tools and tips