IDN Punycode Converter

DNS speaks ASCII only

The domain system accepts a restricted ASCII set, so a domain containing non-Latin characters is encoded into an ASCII form beginning xn--. München becomes xn--mnchen-3ya. The Unicode form is what a browser displays; the Punycode form is what is actually resolved and what appears in certificates and logs.

Homograph attacks exploit the gap

Cyrillic а, е and о are visually identical to their Latin counterparts. A domain using them renders as apple.com and resolves as something entirely different. Browsers defend by displaying the Punycode form when a label mixes scripts or uses a script inconsistent with the browser's locale, which is why a suspicious link sometimes appears as xn-- gibberish — that display is the warning, not a fault.

Encoding is per label

Each dot-separated label is converted independently, so only the labels containing non-ASCII get the xn-- prefix. A domain can mix encoded and plain labels, and a subdomain may be encoded while the parent is not.

Email addresses are a separate standard

Internationalised email uses SMTPUTF8 rather than Punycode for the local part, and support is inconsistent across providers. Punycode applies to the domain half; the part before the @ follows different rules and frequently fails silently.

Verifying a link

Converting a suspicious URL to Punycode reveals whether the visible characters are what they appear to be. A domain that looks entirely Latin but converts to an xn-- form contains non-Latin characters somewhere, which is decisive evidence.