Punycode and IDN domain converter
Convert international domain names to xn-- Punycode and back, compare with the browser’s own conversion and flag lookalike letters.
A clear answer. Here’s how.
Each label (the parts between dots) that is not plain ASCII is encoded with Punycode, the Bootstring algorithm of RFC 3492 implemented here from section 6.3 with the overflow checks of section 6.4, and given the xn-- prefix; xn-- labels are decoded (section 6.2) and re-encoded to check they are canonical. Beside that, the whole name goes through this browser’s URL host parser, which applies the WHATWG URL Standard and UTS #46 processing (case mapping to lower case, Unicode normalisation, mapping of ideographic full stops, nontransitional handling of ß and ς, and rejection of disallowed characters) before Punycode. The table shows both and explains where they differ, for example München becoming xn--Mnchen-3ya under plain Punycode but xn--mnchen-3ya in a browser. A mixed-script check names labels that combine Latin with Cyrillic, Greek or Armenian letters, or consist only of Cyrillic or Greek letters that look Latin, a common homograph trick. This is not the full UTS #39 confusables algorithm, the IDNA2008 contextual rules or a browser’s address-bar display policy, and it does not look anything up in DNS.
How this is checked
5 reference checks passed These 5 cases were run when this page was built, on 20 October 2026, and all reproduce within the stated tolerance. The same cases are part of the automated tests that run on every change to Toolmoz. Engine version 1.
See the checks and where each expected answer comes from
Case 1
- Inputs
- Domain names or labels, one per line bücher.example
- Expected, and what Toolmoz gave
- ASCII (RFC 3492 per label) expected xn--bcher-kva.example, Toolmoz xn--bcher-kva.example
- Where the expected answer comes from
- Wikipedia, Punycode: “bücher” is copied to “bcher”, then ü is coded as the number 745 written kva, so bücher.tld becomes xn--bcher-kva.tld
- Allowed difference
- exact
Case 2
- Inputs
- Domain names or labels, one per line München
- Expected, and what Toolmoz gave
- ASCII (RFC 3492 per label) expected xn--Mnchen-3ya, Toolmoz xn--Mnchen-3yaURL host (UTS #46) expected xn--mnchen-3ya, Toolmoz xn--mnchen-3ya
- Where the expected answer comes from
- Wikipedia, Punycode examples: München encodes as Mnchen-3ya (basic letters keep their case); UTS #46 maps M to m before encoding
- Allowed difference
- exact
Case 3
- Inputs
- Domain names or labels, one per line 日本語.jp
- Expected, and what Toolmoz gave
- ASCII (RFC 3492 per label) expected xn--wgv71a119e.jp, Toolmoz xn--wgv71a119e.jp
- Where the expected answer comes from
- Well-known IDN example 日本語.jp = xn--wgv71a119e.jp, the same as Node url.domainToASCII
- Allowed difference
- exact
Case 4
- Inputs
- Domain names or labels, one per line 他们为什么不说中文
- Expected, and what Toolmoz gave
- ASCII (RFC 3492 per label) expected xn--ihqwcrb4cv8a8dqg056pqjye, Toolmoz xn--ihqwcrb4cv8a8dqg056pqjye
- Where the expected answer comes from
- RFC 3492 section 7.1 sample (B), Chinese (simplified): Punycode ihqwcrb4cv8a8dqg056pqjye
- Allowed difference
- exact
Case 5
- Inputs
- Domain names or labels, one per line xn--Proprostnemluvesky-uyb24dma41aCopy result as unicode
- Expected, and what Toolmoz gave
- Unicode expected Pročprostěnemluvíčesky, Toolmoz Pročprostěnemluvíčesky
- Where the expected answer comes from
- RFC 3492 section 7.1 sample (D), Czech: Pro(ccaron)prost(ecaron)nemluv(iacute)(ccaron)esky, where each parenthesised name is the accented letter, has the Punycode Proprostnemluvesky-uyb24dma41a
- Allowed difference
- exact
What this shows: the engine reproduces independently worked values for these cases. It does not prove every possible input is right. To test an answer you were given, see how to check a number; to see what is and is not checked across Toolmoz, see the accuracy ledger.
See a worked example
Worked example
A fixed demonstration, separate from the values you enter above.
- Domain names or labels, one per line
bücher.example München.de 日本語.jp xn--mnchen-3ya.de аррӏе.com
- Copy result as
- ASCII (xn--) forms
Example result
| Input | Punycode per label (RFC 3492) | URL host in this browser (UTS #46) | Unicode form | Notes |
|---|---|---|---|---|
| bücher.example | xn--bcher-kva.example | xn--bcher-kva.example | bücher.example | Same result |
| München.de | xn--Mnchen-3ya.de | xn--mnchen-3ya.de | München.de | Differs. Upper-case letters: UTS #46 maps them to lower case before encoding; plain Punycode keeps them. |
| 日本語.jp | xn--wgv71a119e.jp | xn--wgv71a119e.jp | 日本語.jp | Same result |
| xn--mnchen-3ya.de | xn--mnchen-3ya.de | xn--mnchen-3ya.de | münchen.de | Same result |
| аррӏе.com | xn--80ak6aa92e.com | xn--80ak6aa92e.com | аррӏе.com | “аррӏе”: Whole-script lookalike: every Cyrillic letter here can pass for a Latin letter. |
The Punycode column is RFC 3492 applied to each label exactly as typed, implemented here. The URL host column is what this browser’s URL parser makes of the whole name (WHATWG URL Standard, UTS #46 nontransitional processing: lower-casing, normalisation, mapping of full stops, and refusal of disallowed characters); browsers built on different Unicode versions can differ slightly. Lookalike warnings are a simple mixed-script check, not the full UTS #39 confusables test that browsers use to decide when to show Punycode in the address bar.