Punycode is the RFC 3492 encoding that turns internationalized domain name (IDN) labels into the pure-ASCII "xn--" form the Domain Name System actually carries on the wire. The DNS protocol was written for a narrow set of characters — basic ASCII letters, digits, and the hyphen — long before the web became multilingual, so any non-ASCII label has to be folded into that limited alphabet before it can be queried, cached, or signed by a certificate authority. Punycode does that fold in a reversible way: given the Unicode spelling "bücher.example", a compliant encoder returns "xn--bcher-kva.example", and given the ASCII form back, the decoder recovers the original Unicode exactly, including the code points above U+FFFF that UTF-16 would split. The encoding is applied per label, the "xn--" prefix acts as a flag that an ASCII-Compatible Encoding follows, and the algorithm is fully deterministic, which is why every standards-compliant implementation agrees on the same canonical ASCII form for the same Unicode input. That determinism is what lets the Punycode Converter produce output that any other RFC 3492 implementation will reproduce.
What Punycode Actually Does in the DNS
The key idea behind Punycode is separability. A domain is a sequence of labels separated by full stops, and only the labels themselves get encoded; the dots stay as ASCII dots so the overall structure of the domain is preserved. The "xn--" prefix is a flag that the rest of the label is the ASCII-Compatible Encoding (ACE) form, and it gets attached to every label that contains non-ASCII code points. Pure-ASCII labels — like "example", "com", or any label written only with letters, digits, and hyphens — are simply lowercased and left unchanged. That is why the prefix only ever appears on the labels that actually need it, and why a name like "shop.bücher.example" becomes "shop.xn--bcher-kva.example" instead of one long ACE blob.
This encoding is also fully reversible. Every Punycode string carries enough information to recover the exact Unicode code points that produced it, which is why "xn--bcher-kva" always decodes to "bücher" and not to some other spelling that just happens to share a few characters. The reversibility is a property of the Bootstring algorithm that RFC 3492 defines, and it is what lets registries, browsers, and certificate authorities all reach the same canonical ASCII form when they need one. Without that shared canonical form, the DNS would not know whether "bücher" and "b\u00FCcher" were the same label or two different labels — Punycode forces a single answer.
The Bootstring Algorithm in Plain Language
RFC 3492 specifies a Bootstring algorithm with a small set of fixed constants. These constants are not tuning knobs the tool adjusts; they are part of the specification, and any implementation that changes them will produce a different (and incompatible) ASCII form. The values are:
| Constant | Value | Purpose |
|---|---|---|
| base | 36 | Number of basic code points the encoder distinguishes per variable-length integer digit. |
| tmin | 1 | Minimum bias threshold for general-case delta encoding. |
| tmax | 26 | Maximum bias threshold for general-case delta encoding. |
| skew | 38 | Adjustment applied when bias would otherwise grow faster than the encoded value. |
| damp | 700 | Damping factor applied to bias after each delta-encoded code point. |
| initial bias | 72 | Starting bias used before the first non-basic code point is encoded. |
| initial code point | 128 | First non-basic Unicode code point considered for delta encoding. |
In plain language, the encoder walks through each label one Unicode code point at a time. Existing basic ASCII characters are copied through first, and only the non-ASCII code points are encoded as variable-length deltas — numbers that describe where each new non-ASCII code point sits relative to the previous one. The bias term adapts as more values are processed, which lets the algorithm pack dense, related scripts efficiently while leaving room for sparse ones. The result is an ASCII string made of basic letters, digits, and hyphens, prefixed with "xn--" once encoding is done. The decoder is the inverse: it consumes those deltas, applies the same adaptive bias, and rebuilds the original Unicode scalar values.
Because the algorithm iterates full code points rather than UTF-16 code units, supplementary characters — emoji and rare historic scripts that sit above U+FFFF — stay intact instead of being silently split in half. Arithmetic overflow checks on delta multiplication and weight accumulation keep the implementation stable when a label contains many non-ASCII code points. For the full parameter reference and the boundary behaviour at tmin and tmax, see the Punycode Converter Cheat Sheet: RFC 3492 Rules and Limits.
How to Use the Punycode Converter
The Punycode Converter processes a single domain name locally in the browser and exposes the raw RFC 3492 conversion. The steps to get a clean result are:
- Paste only a domain name into the input — no scheme, no path, no query, no port, no fragment. Unicode full stops commonly used in CJK text are normalized to an ASCII dot before the labels are split.
- Choose a direction. Use Unicode-to-ASCII when you need an xn-- name for a DNS field, certificate signing request, or hostname validator. Use ASCII-Punycode-to-Unicode when an xn-- label has appeared in a URL, log, or certificate and you want to see what it actually spells.
- Convert. The tool splits the input on dots and runs each label through the Bootstring algorithm. A label that contains non-ASCII code points receives the xn-- prefix; a plain ASCII label is lowercased and left otherwise unchanged. Decode mode only applies Bootstring decoding to labels that actually carry the prefix.
- Inspect every label. Confirm that only the labels you expect carry "xn--", that the ASCII portion still reads like the rest of the name, and that no label is empty or truncated.
- Copy the result and validate it with the target registry, certificate authority, or URL library. If a registrar rejects the name, follow that registry's IDN policy rather than re-encoding or swapping characters blindly.
What the Converter Accepts and What It Refuses
The tool is intentionally narrower than a full browser URL parser. It does not accept a scheme like "https://", does not parse paths, ports, query strings, or fragments, and does not perform percent decoding, resolve DNS, test registration availability, or contact a registry. Pasting a full URL like "https://bücher.example/page" will either be rejected or treated as garbage; extract the domain first, then convert. Empty labels, malformed digits, invalid Unicode scalar values, and inputs above 1,000 code points are rejected outright so the conversion cannot silently produce a wrong-looking ASCII string.
A few conventions are worth knowing. Unicode full stops that CJK text often uses in place of an ASCII dot are normalized to an ASCII dot before the labels are split. The Bootstring implementation iterates full Unicode code points rather than UTF-16 halves, so supplementary characters survive intact. Label length limits and registry policies still apply after conversion — a syntactically valid xn-- label can still be too long, reserved, blocked, or simply unregistered, and the conversion step will not warn you about any of that. Copy the ASCII result into the authoritative consumer — the registrar search box, the certificate authority form, or a standards-compliant URL library — and let that consumer make the final acceptance decision.
Why Decoded Unicode Is Not Always Safe
Punycode is not a language translator. Decoding "xn--bcher-kva" tells you the Unicode spelling the label represents, but it does not tell you how to pronounce the name, who owns it, or whether it belongs to the organization it resembles. The characters of Cyrillic, Greek, and Latin scripts overlap heavily; a Latin "a" and a Cyrillic "а" look identical to most readers, and many other pairs do too. That overlap is exactly what homograph attacks exploit: a domain spelled with mixed scripts can read like a trusted brand while pointing somewhere else entirely.
A valid conversion is therefore never proof that a domain is trustworthy. Before visiting a decoded URL, compare each label, writing system, and organization carefully. Treat the converter as a reversible encoding step, not a security filter — keep anti-phishing checks, allowlists, and registry validation on a separate layer from the raw encoding work. The Punycode Converter runs entirely in your browser and never contacts a registry, which is exactly why it is safe to use on suspicious names for inspection but also exactly why it cannot vouch for what you have inspected.
Why Browsers and Registrars Can Disagree
The raw RFC 3492 conversion is the smallest possible piece of an IDN pipeline. Production URL systems typically layer three extra steps on top of it: Unicode normalization (usually NFC) to fold equivalent sequences into a canonical form, UTS #46 mapping to handle compatibility characters and case folding rules, and the contextual IDNA2008 rules that some registries apply to block scripts, mixed-script combinations, or certain code points. A browser's address bar will often show "xn--bcher-kva" as "bücher" because the browser applied those layers before displaying the name; the Punycode Converter exposes the raw RFC 3492 label without them, which is why its output can disagree with what the browser displays.
This is also why a registrar can reject a name that the tool happily accepts: the registrar is enforcing IDNA2008 plus its own per-script policy on top of the raw encoding, while the converter is showing only the encoding. The WHATWG URL Standard documents the additional steps that browsers apply, and that document is the right reference when the gap between raw Punycode and what the browser accepts becomes a problem. When a registrar rejects a converted result, read that registry's published IDN policy and adjust the Unicode input to match it — do not re-encode or hand-edit the ASCII output. Treat the converter as the documented reversible step and leave the policy decisions to the registry's own rules.