Punycode Converter

About the Punycode Converter

International domain names such as bücher.de or 例え.テスト travel through DNS in an ASCII form, the A-label: xn-- followed by the name in Punycode (xn--bcher-kva.de). Paste a list of domains, e-mail addresses or URLs, one per line, and this page converts each one both ways: Unicode names to Punycode with your browser’s own IDNA processing, and xn-- labels back to Unicode, checking that each converts back to exactly the same label.

Every name also gets the checks that matter when a link looks wrong or before you register a name: the script of each label, the UTS #39 look-alike rules (a Cyrillic а in аpple.com, or аррӏе.com written entirely in Cyrillic letters), characters that IDNA2008 registries refuse, invisible characters, ß-style characters that older software turns into a different name, and the DNS length and hyphen rules.

Without a pass you see a free preview: every count and the verdict of each name that needs a look in full, with the first rows of the conversion table. The whole table, copying the Punycode and Unicode lists and the CSV unlock with a Pro pass.

Common uses

• Checking a link in an e-mail or message whose domain looks familiar but feels wrong, before you sign in: look-alike letters, a user name before @, a backslash or a percent-encoded host.
• Converting a list of international domains or e-mail addresses for a system that only accepts ASCII (mail servers, certificate requests, DNS zone files, firewalls, ad and analytics filters).
• Turning xn-- names from logs, certificates and DNS records back into what people actually read.
• Testing an international name before you register it: scripts, IDNA2008 characters, hyphens and length.

How the conversion works

To ASCII, the page hands each host to your browser’s URL parser, which applies Unicode’s IDNA processing (UTS #46) the way the URL Standard asks: Nontransitional processing, with the Bidi rule and the joiner rules checked. That maps the name first (capital letters to lower case, full-width letters to normal ones, invisible characters such as the soft hyphen dropped) and then writes each international label as xn-- and its Punycode (RFC 3492). So the result is exactly where a link to that name goes in this browser.

To Unicode, each xn-- label is decoded with RFC 3492 and converted back: RFC 5891 §5.3 asks an application that shows names to reject a label that does not come back the same. The URL Standard has browsers lower-case an all-ASCII host without checking its xn-- labels, so a link can carry what RFC 5890 calls a Fake A-label: one that is not valid Punycode, decodes to plain ASCII or to a character IDNA does not allow, or is not the form the browser itself would write. This page names the reason.

Look-alike checks (UTS #39)

UTS #39, Unicode Security Mechanisms defines how to tell whether a string mixes scripts: each character’s scripts (with Japanese, Korean and Han-with-Bopomofo treated as one writing system each) are intersected; when nothing is left, the label is mixed-script. Its restriction levels grade the mix: ASCII-Only, Single Script, Highly Restrictive (Latin with Chinese, Japanese or Korean), Moderately Restrictive (Latin with one other Recommended script of UAX #31, except Cyrillic and Greek) and Minimally Restrictive (anything else). This page gives each label its level and flags:

• Mixed scripts at the lowest level as a look-alike risk: аpple (Cyrillic а and Latin pple) or gοοgle (two Greek omicrons).
• Whole-script look-alikes: a label in one non-Latin script whose letters all look Latin, such as Cyrillic аррӏе. It reads as the ASCII name you would expect, found by replacing each character with its look-alike from Unicode’s confusables data. Under a top-level domain of the same script (.рф) it is only something to check, since names there are expected to be Cyrillic.
• Latin with another script at the Moderately Restrictive level as something to check.

Browsers apply rules of their own. Chrome decides for each label whether to show Unicode or Punycode; its checks include a script-mixing check built on UTS #39’s Highly Restrictive profile, under which Latin, Cyrillic and Greek never mix and ASCII letters mix only with Chinese, Japanese or Korean characters (Chromium’s IDN display policy).

What browsers accept and registries refuse

Browsers convert more than registries allow. IDNA2008 (RFC 5892) derives which characters a domain may hold: letters, digits and marks, with listed exceptions; symbols and emoji are not allowed, so i❤.ws converts in a browser but is refused wherever IDNA2008 is the rule. A few characters are allowed only in context (a middle dot only between two l’s, as in Catalan l·l). The page derives each character’s status with RFC 5892’s rules and flags the rest.

Four deviation characters — ß, the Greek final ς, and the zero width joiner and non-joiner — are kept under IDNA2008 and the URL Standard that browsers follow, but changed by software that still uses UTS #46’s deprecated Transitional processing (ß → ss): faß.de and fass.de are different domains, and such software sends you to the second.

The ASCII form is also checked against DNS: a label holds at most 63 characters and a name 253 (RFC 1035 §2.3.4, 255 octets on the wire); host names can’t start or end a label with a hyphen, and hyphens in the 3rd and 4th places are reserved for forms such as xn-- (RFC 5890 §2.3.1).

E-mail addresses and URLs

Only the domain of an e-mail address has an ASCII form. A local part with non-ASCII characters (имя@пример.рф) can only be delivered when every mail server on the way supports SMTPUTF8 (RFC 6531), and RFC 6530 discourages Punycode in the domain of such an address, so keep it in Unicode. In a URL only the host is converted; browsers percent-encode non-ASCII characters in the path and query themselves.

A web address can also hide where it leads without a single international character, and the page flags these too, naming the host the browser goes to (URL Standard):

• What comes before the last @ is a user name, not the site: https://mybank.example@phish.example/ goes to phish.example.
• A backslash counts as a slash: https://phish.example\@mybank.example/ goes to phish.example.
• Percent-encoded characters in the host are decoded first: https://ex%61mple.com/ goes to example.com.

Limitations

• The ASCII form comes from your browser’s own IDNA processing, which follows the Unicode version it ships with; an older browser may refuse a recently added character, or treat a rare one differently.
• The look-alike check knows the characters that look like ASCII letters and digits (from Unicode’s confusables data). Look-alikes between two non-Latin scripts and typos that stay in ASCII (rn for m, 1 for l) are not flagged; the Suspicious Link Checker compares links with well-known names.
• The IDNA2008 status of each character is derived with the rules of RFC 5892 from your browser’s Unicode data. Registries use the IANA tables for their own Unicode version and add rules of their own (which scripts a top-level domain accepts), so a registry can still refuse a name that passes here.
• It converts and checks names; it does not look them up. To see whether a domain exists and who runs it, use the DNS Lookup or the WHOIS Lookup.
• Up to 5,000 lines are read in one run; split a longer list.

Privacy

On this device: nothing is sent

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.