Punycode Encoder / Decoder

What this tool is used for

• Producing the ASCII form of an internationalised domain for a DNS zone file or a registrar form.
• Decoding an `xn--` label from a certificate or a log line to see the name it actually represents.
• Auditing a list of domains for look-alikes by comparing encoded rather than rendered forms.
• Putting a non-ASCII hostname into configuration whose parser is ASCII-only.
• Checking that an encoded label still fits the length limit DNS imposes on it.

Frequently Asked Questions

What do the xn-- prefixed domains mean?

`xn--` is the IDNA ACE prefix, and it marks a label that is really Unicode. `münchen.de` is transmitted as `xn--mnchen-3ya.de`; DNS itself only ever carries ASCII, so every internationalised domain is stored and resolved in this form.

How does Punycode fit Unicode into ASCII?

RFC 3492's generalised variable-length encoding. ASCII characters are copied out first, a hyphen marks where they end, and the remainder encodes the non-ASCII code points as deltas in a base-36 alphabet with a self-adjusting bias (tmin 1, tmax 26, skew 38, damp 700).

Why is it encoded label by label?

Because each dot-separated label is encoded independently — `münchen.de` gives `xn--mnchen-3ya` plus an untouched `de`. A label is capped at 63 bytes *after* encoding, which is why a long non-Latin name can be rejected even though it looked short.

What is a homograph attack?

Registering a domain whose Unicode form looks identical to a real one — Cyrillic а (U+0430) in place of Latin a. Browsers now show the raw `xn--` form when a label mixes scripts, which is exactly why decoding a suspicious URL here is worth doing before clicking.

Does the encoding change the case?

Punycode is case-insensitive on input and its output alphabet is lowercase, and IDNA normalises before encoding — so `MÜNCHEN.de` and `münchen.de` reach the same ASCII label. Do not treat a decoded name as preserving the case someone typed.

Why is the encoded form so much longer than the original?

Because it encodes each non-ASCII character as a delta from the previous one, and characters far apart in the code space cost more digits. A label mixing scripts encodes worse than one staying within a single script.

What happens if a label is already ASCII?

Nothing — it is left alone with no `xn--` prefix, since there is nothing to encode. That is why only the non-ASCII labels of a mixed domain carry the prefix, and the rest of the name looks normal.

Common errors and gotchas

• Encoding across a dot. Labels are encoded independently, so a prefix spanning two labels is always wrong.
• Prefixing a pure-ASCII label with `xn--`. Such labels pass through unchanged, and adding the marker invalidates them.
• Trusting the rendered form. Distinct code points can render identically, which is the entire basis of a homograph attack.
• Expecting the original case back. Encoding normalises it, so a round trip is not guaranteed to be byte-identical.
• Assuming the encoded form is shorter. It is usually longer, and can push a label past the 63-character limit.