Punycode / IDN Converter

What it does

This converter translates internationalized domain names (IDNs) between the form people read and the form the DNS stores. Type bücher.example and you get xn--bcher-kva.example; paste an xn-- name and you get the Unicode original. It works in both directions as you type, label by label, so in shop.bücher.example only the label with non-ASCII characters gains the xn-- prefix.

The encoding is Punycode (RFC 3492), implemented in JavaScript inside your browser; nothing you type is sent anywhere. Before encoding, the tool lowercases each label and applies Unicode NFC normalization, so a precomposed ü and a u followed by a combining diaeresis give the same result. It does not apply every IDNA2008 or UTS #46 mapping rule, so a successful conversion is a correct encoding, not proof that a registry will accept the name.

Next to the result you get a breakdown of every label (Unicode form, ASCII form and length), a check against the DNS limits of 63 octets per label and 253 for the full name, and a warning when a single label mixes scripts, such as Latin with Cyrillic or Greek.

How to use it

1. Type or paste a domain name, a full URL or an email address.
2. Watch the converted form update: Unicode input yields the xn-- form, and xn-- input yields Unicode.
3. Read the label breakdown for lengths, limit errors and any mixed-script warning.
4. Copy whichever form the destination expects.

With a URL, only the host is converted; the rest stays as entered. (On the web, non-ASCII characters in a path or query string are percent-encoded as UTF-8, not converted to Punycode.) With an email address, only the part after the @ is converted. A local part such as jürgen has no Punycode form; delivering mail to it requires SMTPUTF8 support (RFC 6531) on every server along the way.

Use cases

• Checking a suspicious link. Paste a URL from a message before opening it. If the host decodes to letters from two scripts, or a familiar-looking name turns out to be an xn-- label, look closer before clicking.
• Writing DNS records. Zone files and most DNS hosting panels expect the ASCII form. Use that exact string wherever a record refers to the name, including CNAME targets and MX hosts.
• Requesting TLS certificates. Certificate authorities and ACME clients take the xn-- form in subject alternative names. Decoding a certificate's SAN list shows which Unicode names it really covers.
• Reading logs. Web server logs, HTTP Host headers and TLS SNI values carry the encoded name. Decode an unfamiliar entry to read it.
• Setting up mail for an IDN. MX, SPF, DKIM and DMARC records all sit under the xn-- name, and an address like info@xn--bcher-kva.example works with ordinary mail software.
• Checking length before registering. Encoding expands some scripts considerably: the seven-character Thai label ภาษาไทย becomes xn--o3crh0a8bb0k, 16 octets, so a label that looks short can still exceed 63.

Records and a certificate signing request for bücher.example use the encoded name like any other host name:

xn--bcher-kva.example.      3600 IN A     192.0.2.10
www.xn--bcher-kva.example.  3600 IN CNAME xn--bcher-kva.example.
xn--bcher-kva.example.      3600 IN MX    10 mail.xn--bcher-kva.example.

openssl req -new -key site.key -out site.csr \
  -subj "/CN=xn--bcher-kva.example" \
  -addext "subjectAltName=DNS:xn--bcher-kva.example,DNS:www.xn--bcher-kva.example"

How Punycode fits Unicode into a host name

Strictly, the DNS wire format can carry any byte values. In practice, host names have been limited to ASCII letters, digits and the hyphen since the 1980s (the LDH rule of RFC 952 and RFC 1123), and resolvers, mail servers and certificate checks were built on that assumption. Rather than change them, IDNA converts names inside the application, before any query is sent, into a string that already obeys the old rule.

Punycode works in two stages. First it copies the label's ASCII characters in order and adds a hyphen if there were any: bücher gives bcher-. Then it describes each missing character as one number that says which code point to insert and where. The ü is U+00FC, decimal 252. Counting up from 128, with five letters already placed and therefore six possible insertion slots, the number is (252 − 128) × 6 + 1 = 745, where the final 1 means after the first letter. That number is written in a variable-length base-36 form using a–z and 0–9, with thresholds that adapt so small numbers stay short. It comes out as kva, giving xn--bcher-kva.

Decoding reverses this: everything before the last hyphen is copied, and the characters after it are read back as insertions. A label with no ASCII letters, like the Thai one above, has no separating hyphen after the prefix. Because the encoded label is what travels through DNS, the 63-octet limit applies to it, not to the Unicode text.

Look-alike domains and the address bar

Many letters in different scripts look identical. The Cyrillic а (U+0430) matches the Latin a in most fonts, so bаnk.example with a Cyrillic second letter reads as an ordinary word yet encodes to xn--bnk-6cd.example. This is a homograph attack.

Browsers decide label by label whether to show Unicode or the xn-- form. Policies differ by vendor, but common tests include whether a label mixes scripts in combinations real names rarely use, whether it is spelled entirely in letters that imitate Latin ones, and whether it closely resembles a well-known domain. In Firefox, setting network.IDN_show_punycode to true in about:config forces the ASCII form for every name.

The mixed-script warning here looks for more than one script inside a single label. A label spelled entirely in Cyrillic letters that resemble Latin ones is not mixed, so a clean result does not prove a name is genuine. Compare the decoded name with the address you expected, and when in doubt type the address yourself.

Frequently asked questions

A clean conversion shows the name is encoded correctly, not that it is registrable or safe. Registries apply their own character rules, and look-alike names can avoid mixing scripts.