Punycode Converter

The DNS only speaks ASCII. That was fine when every domain ended in .com, .org, or a country code and the letters in between came from the Latin alphabet. It stopped being fine the moment people wanted to register domains in Chinese, Arabic, Cyrillic, or with German umlauts. Punycode is the clever compromise: an algorithm that encodes Unicode labels into ASCII-compatible strings prefixed with xn-- so DNS infrastructure unchanged from 1983 can still route them.

This Punycode converter handles both directions. Paste münchen.de and get xn--mnchen-3ya.de, the form your registrar, DNS server, and SSL certificate provider actually need. Paste xn--nxasmq6b.example and read back its Unicode meaning. It works on full domain names (handling each label separately) and on standalone labels, and it decodes as well as encodes so you can verify what you are actually registering.

Punycode exists because IDN (internationalized domain names) are a fact of the modern web. Chinese, Russian, Indian, and Arabic-speaking markets register domains in their native scripts. Emoji domains exist for novelty and brand protection. But web servers, email systems, and certificate authorities all still transmit these as ASCII under the hood. Understanding Punycode prevents surprises when your monitoring, logging, or CSP configuration shows weird xn-- strings instead of the pretty domain you registered.

Punycode is defined by RFC 3492 and used within IDNA specifications (RFC 5890-5894 for IDNA2008, superseding the older RFC 3490 IDNA2003). The algorithm is called Bootstring, and it works by separating a Unicode string into its ASCII characters (the "basic" code points) and its non-ASCII characters (the "extended" ones), then encoding insertion positions using a compact delta-encoded scheme.

Each label in a domain is encoded separately. The string münchen.de becomes two labels: münchen and de. Only labels containing non-ASCII characters get the xn-- prefix. Pure ASCII labels pass through unchanged. After encoding, münchen becomes xn--mnchen-3ya: the basic characters (mnchen) appear first, then a hyphen separator, then the Bootstring-encoded deltas for the ü insertion point (3ya).

IDNA2008 tightened character rules to prevent homograph attacks — domains that look visually identical using characters from different scripts. Registries now apply script-mixing restrictions and often disallow dangerous combinations. Browsers decide whether to display the Unicode form or the Punycode form based on TLD policy, the scripts used, and user preferences. Chrome and Firefox show Punycode (xn--) for domains mixing scripts that commonly enable phishing, but display Unicode for well-defined single-script domains in supported TLDs.

Writing your own Punycode encoder is possible but production systems use a well-tested IDNA library because edge cases around normalization, bidi, and disallowed characters are subtle. Browser DevTools and WHOIS results show mixed Punycode and Unicode depending on policy, which makes debugging confusing without a dedicated converter. Command-line tools exist (idn, punycode in Node REPL) but require installation. This tool runs in the browser, handles full domains, flags homographs, and works offline after first load.