Punycode / IDN Converter — Unicode ⇄ xn--

Real-world use cases

• Register a Chinese-language domain and get the xn-- form for your DNS panel

  You bought "中文.中国" from a registrar but your DNS host, CDN, and TLS certificate issuer all want the ASCII form. Workflow: paste "中文.中国" into the encode direction, read back "xn--fiq228c.xn--fiqs8s", and copy it into the A-record field, the CDN origin, and the SAN list of your certificate request. The per-label breakdown confirms that both the second-level label and the ".中国" TLD encoded separately, which is exactly what the registry expects — getting one label wrong silently breaks resolution with no error message.

• Investigate a suspicious link that might be a homograph attack

  A phishing email links to a host shown as "xn--pple-43d.com". You can't read it by eye. Paste it into the decode direction and it resolves to "аpple.com" — with a Cyrillic "а" (U+0430), not a Latin "a". That single decoded character is your proof the link impersonates Apple. Pair the decoded Unicode with the unicode-character-inspector to confirm the exact code point, then report or block the domain. Doing this in a 100% client-side tool means you never hand the attacker's URL to a third-party server.

• Send mail to an internationalized domain through a legacy SMTP relay

  Your application has to deliver to "support@почта.рф" but the downstream relay predates SMTPUTF8 and rejects non-ASCII domains. Paste the full address into the encode direction; only the domain converts, giving you "support@xn--80a1acny.xn--p1ai" with the local part untouched. Drop that into the envelope recipient and the legacy relay accepts it. The email-aware split saves you from manually slicing on the "@" and accidentally encoding the local part too.

• Audit a multi-level internationalized hostname before deployment

  Your staging host is "测试.shop.中文.com" and you need to know which labels become xn-- and which stay ASCII before you wire up wildcard certificates and CORS allow-lists. Paste it, turn on the per-label breakdown, and you see "测试 → xn--0zwm56d", "shop → shop", "中文 → xn--fiq228c", "com → com". Now you know the exact ASCII host your origin server, CORS policy, and HSTS preload entry must use — mixing the Unicode and ASCII forms across configs is a common source of "works in Chrome, fails in curl" bugs.

• Convert a batch of internationalized domains for a config file

  You're migrating a whitelist of fifty internationalized vanity domains into an nginx server_name list, which must be ASCII. Paste all fifty, one per line, into the encode direction and copy the xn-- column out in one shot. Each line converts independently, and a malformed entry shows an inline error rather than poisoning the whole batch — so you fix the one bad row instead of re-running the lot.

Common pitfalls

• Encoding the whole domain as one string. Punycode operates per label — you must split on "." and encode each label separately. Encoding "münchen.de" as a single chunk produces garbage; the dot is a label boundary, not a character to encode. This tool always splits on "." for you.

• Forgetting that "xn--" is case-insensitive but the payload after it is not arbitrary. "xn--MNCHEN-3YA" and "xn--mnchen-3ya" decode the same (DNS is case-insensitive), but flipping a single payload character yields a different or invalid domain. Always round-trip through a real codec — never hand-edit the ACE string.

• Skipping UTS-46 normalization before registration. Typing "MÜNCHEN.DE" and encoding it gives a technically valid but non-canonical result; registrars lowercase and NFC-normalize first, so you may end up with a different xn-- than the one actually registered. Normalize (lowercase + NFC) before you encode for any name you intend to register.

Privacy