Punycode / IDN Converter

What is Punycode?#

The Domain Name System was built on ASCII — the letters A-Z, digits, and the hyphen. So how does a browser resolve a domain like 中文.com or münchen.de, whose characters are not in that alphabet? The answer is Punycode (and the IDN framework around it): a reversible encoding that turns each non-ASCII label into an ASCII-safe form beginning with the prefix xn--. The DNS only ever sees xn--fiq228c.com; the browser shows you 中文.com.

This tool converts in both directions:

• To ASCII takes a Unicode domain or email and produces the xn-- form that DNS and certificates actually carry. Each label is converted independently — münchen.中文.com becomes xn--mnchen-3ya.xn--fiq228c.com, with the trailing .com left alone because it is already ASCII.
• To Unicode does the reverse: it reads xn-- labels back into the human-readable script.

Email is handled too. The tool detects the @, converts only the domain part, and leaves the local part (the mailbox name) untouched — so Büchner@中文.com becomes Bü[email protected], never a mangled whole-string conversion.

How to use it#

1. Pick To ASCII or To Unicode from the toggle at the top-left. The tool also suggests a direction when it notices an xn-- label in your input.
2. Paste a domain or an email into the Input pane. The header shows whether it was recognised as a domain or an email.
3. The converted result fills the Output pane; click Copy to take it.
4. Below the panes, the per-label breakdown table shows each label and what it became — handy when a long domain has several non-ASCII labels and only some changed.
5. Use Swap to move the output back into the input and flip the direction (a quick round-trip check), Sample to load münchen.中文.com, and Clear to reset.

Key features#

• Both directions, each label on its own. Every label is converted independently and the breakdown table shows exactly which ones changed and which stayed ASCII.
• Email-aware. A single @ is detected and the mailbox name is preserved; only the domain side is encoded. Input with multiple @ characters is rejected with a clear message rather than silently corrupting the result.
• Separator normalisation. The full-width dot ．, the ideographic full stop 。, and the halfwidth ｡ are all treated as the ASCII . they really are in IDN, so pasted text does not break.
• Strict on malformed input. A bad xn-- label (for example xn--!!) raises a clean error pointing at the offending label, instead of producing a wrong domain.
• Honest about scope. The compliance note below the tool states plainly that this implements the Punycode encoding and the mapping step — it is not a full IDNA2008 validity checker, so a technically-invalid ACE label may still decode here.

Worked example#

Converting To ASCII, the placeholder münchen.中文.com becomes:

xn--mnchen-3ya.xn--fiq228c.com

The breakdown shows three labels, two of them converted: münchen → xn--mnchen-3ya, 中文 → xn--fiq228c, and .com untouched because it was already ASCII. Flip to To Unicode and paste the result back to recover münchen.中文.com exactly.

A few more real conversions worth seeing:

中文.com           → xn--fiq228c.com
münchen.de        → xn--mnchen-3ya.de
😂.com             → xn--g28h.com
café.fr           → xn--caf-dma.fr
日本語.jp          → xn--wgv71a119e.jp
Büchner@中文.com   → Bü[email protected]   (email: mailbox preserved)

The last one is the case that catches people out: naive tools encode the whole string and break the address. Here only the domain part after @ changes.

FAQ#

Why does my emoji domain convert to such a short xn-- label?#

A single-character emoji domain like 😂.com becomes xn--g28h.com because Punycode is extraordinarily compact for a label with one non-ASCII character followed by ASCII — it encodes the positions and code points of the non-ASCII characters relative to the ASCII ones, so a one-character label needs very few bytes. Longer or more varied non-ASCII labels produce longer ACE strings.

The output looks the same as the input — did anything happen?#

If every label in your input is already pure ASCII (for example example.com), there is nothing to encode, and the output equals the input. The breakdown table is the reliable indicator: a label whose output matches its input was not converted, because it did not need to be.

I pasted an email and the local part was not converted. Is that correct?#

Yes, and it is deliberate. Internationalised email (SMTPUTF8) allows UTF-8 in the mailbox name, but converting it to xn-- is wrong for the common case — the local part is not a DNS name and is not resolved by Punycode. This tool converts only the domain side, which is the part that has to be DNS-safe. That is also why multiple @ characters are rejected: they make “the domain side” ambiguous.

Can I use the ASCII form to register or resolve any domain?#

For resolution by any modern browser or resolver, yes. For registration, the rules are stricter: IDNA2008 disallows certain characters and normalisations that older mappings (IDNA2003) allowed. This tool does the encoding faithfully but does not run the full IDNA2008 validity checks, so a string that encodes cleanly here might still be rejected by a registrar. When in doubt, confirm with your registrar’s lookup tool.