Punycode is the RFC 3492 Bootstring encoding that maps non-ASCII Unicode code points into the basic ASCII letters, digits, and hyphens accepted by the Domain Name System. It works label by label, copies any ASCII characters first, then encodes each remaining code point as a variable-length delta while an adaptive bias parameter shifts the cost of new characters. The constants are fixed by the specification and rarely change, which is why a single cheat sheet covers almost every conversion you will ever do. Use the Punycode Converter as your cheat sheet for label-level conversions: paste a domain, pick the direction, and the tool processes every label locally with the documented Bootstring constants, applies the xn-- prefix only to labels that contain non-ASCII code points, and rejects malformed input before it can silently produce a wrong result. The output is deterministic for the declared raw RFC 3492 convention, which makes it easy to compare against a reference implementation or a library you trust.
RFC 3492 Bootstring Constants at a Glance
The RFC 3492 specification pins the Bootstring algorithm to seven numeric constants. The Punycode Converter uses the same values, so the table below is also a cheat sheet for what the tool computes under the hood.
| Constant | Value | Role in the algorithm |
|---|---|---|
| base | 36 | Radix used for the variable-length integer encoding of delta values |
| tmin | 1 | Lower threshold where bias adaptation kicks in |
| tmax | 26 | Upper threshold where bias stops adapting further |
| skew | 38 | Dampening term applied to the bias formula |
| damp | 700 | Bias multiplier applied after each output character |
| initial bias | 72 | Starting bias value before any delta is emitted |
| initial code point | 128 | First non-basic code point considered (first non-ASCII) |
Two implementation details sit on top of these constants and are worth keeping on the same page. First, the converter iterates Unicode code points rather than UTF-16 code units, so supplementary characters above U+FFFF survive round-trips intact. Second, arithmetic overflow checks guard the delta multiplication and weight accumulation, which prevents a long label from silently producing a wrong encoded string when intermediate values approach the limit of the runtime's integer range.
Label Prefix and Boundary Rules
Punycode only operates on a single label at a time. Full stops separate labels and are not part of the encoded payload, so the cheat sheet for boundaries is short: split on the dot, encode or decode each piece, then rejoin with an ASCII dot. Unicode full stops that show up inside CJK text are normalized to an ASCII dot before the labels are processed, which keeps the boundary rule consistent regardless of which dot was typed.
Only labels that contain at least one non-ASCII code point receive the xn-- prefix after encoding. An ordinary ASCII label is simply lowercased and left otherwise unchanged — no prefix, no padding, no transformation. In decode mode, only labels that already carry the xn-- prefix are passed through Bootstring decoding; everything else passes through untouched. That is the entire boundary contract, and it is the reason a multi-label domain such as bücher.example encodes as xn--bcher-kva.example rather than every label gaining a prefix.
Accepted Inputs and Rejected Edge Cases
The cheat sheet for what the tool will accept is intentionally narrow:
- A bare domain name, with or without the xn-- prefix on individual labels.
- Unicode code points in the valid scalar range, including supplementary characters above U+FFFF.
- Labels separated by an ASCII dot or by a Unicode full stop normalized to an ASCII dot.
- Total input at or below 1,000 code points across all labels.
The converter will refuse to run on the following inputs and surfaces a clear error rather than guessing:
- Empty labels, which includes a leading dot, a trailing dot, or a doubled dot.
- Malformed digits inside an ASCII label that is supposed to be Bootstring-decodable.
- Invalid Unicode scalar values, including lone surrogates passed in as text.
- Inputs above the 1,000 code point ceiling, which protects against runaway computation.
If a registrar or DNS consumer rejects the result after a syntactically valid conversion, follow the registry's IDN policy rather than altering characters blindly. Label length caps and reserved-block rules live outside the converter's scope.
How to Use the Punycode Converter as a Quick Reference
- Paste a single domain name into the input field. Do not include a scheme, path, port, query, or fragment — the tool only handles the domain.
- Choose the direction: Unicode-to-ASCII when the domain contains non-ASCII code points and a DNS or certificate field expects the ASCII form, or ASCII-Punycode-to-Unicode when you want to inspect an xn-- name before visiting it.
- Run the conversion and inspect every label. Confirm that the xn-- prefix only appears on labels that actually contained non-ASCII code points, and that ordinary ASCII labels were just lowercased.
- Copy the converted domain with the copy button. The result is exactly the converted domain string, with no scheme or trailing slash attached.
- Validate the result with the authoritative consumer — the target registry, a standards-compliant URL library, or both — and visually compare each label, writing system, and organization before you treat the name as trustworthy.
Encode vs Decode Mode Quick Reference
The two modes answer different questions. The table below summarizes when to use each one without re-reading the whole specification.
| Use encode mode when | Use decode mode when |
|---|---|
| A DNS zone file, certificate signing request, or API field only accepts ASCII. | You received an xn-- name from a log, ticket, or email and want to read it. |
| You need to confirm the exact ASCII label a registry will receive after raw RFC 3492 encoding. | You are auditing for look-alike characters across writing systems before visiting the site. |
| You are debugging a label whose Bootstring output should match a fixture in your test suite. | You want to verify that supplementary characters above U+FFFF survive the round-trip. |
Decode mode only applies Bootstring decoding to labels that already carry the xn-- prefix, so an ordinary ASCII label in the same input passes through unchanged. For a deeper walkthrough of reading xn-- labels, see Convert Punycode to Unicode: Read xn-- Labels.
When Browsers Disagree with Raw RFC 3492
Production URL systems — including every modern browser — apply UTS #46 mapping, Unicode normalization, and contextual IDN rules before the label is handed to the Bootstring encoder. The Punycode Converter deliberately does not perform those steps. It exposes the raw RFC 3492 label conversion, which means a browser may still show a result that differs from what the tool prints.
When that happens, treat the converter's output as the canonical raw encoding and the browser's display as the post-mapped version. If a registrar rejects the label, follow that registry's IDN policy. Do not invent characters to force acceptance: a valid conversion is not proof that the name is available, reserved only for you, or trusted by the registry that owns the suffix.
For full application URLs, let a standards-compliant URL library handle scheme, percent-encoding, path, query, and fragment. The converter is the right tool for the label itself; everything around the label belongs to the URL parser.
Look-Alike Characters After Decoding
Decoding an xn-- name exposes the Unicode spelling it represents. It does not tell you how to pronounce the word, who owns the domain, or whether the characters belong to the organization they resemble. Latin, Greek, Cyrillic, and CJK code points can all be visually close enough to mislead, which is exactly the surface that homograph attacks rely on.
Use the decoded form to compare the writing system against the organization you expect — a bank in Germany will not normally register a name spelled with mixed Cyrillic letters, and a Japanese retailer will not normally publish a domain made entirely of Latin characters that look like Japanese. Treat the conversion as one signal among many: a valid xn-- output is necessary, not sufficient, for a domain to be safe to visit or to trust.
If you're weighing options, XOR Encryption Online Cheat Sheet: Formats and Keys covers this in detail.