Punycode is the RFC 3492 Bootstring encoding that represents non-ASCII domain labels using only basic ASCII letters, digits, and hyphens, and converting punycode to Unicode means running that encoding in reverse so a label such as xn--bcher-kva displays as bücher. The conversion is purely textual: it never resolves DNS, contacts a registry, or visits a host. To convert punycode to Unicode in a browser, paste the ASCII domain, pick the ASCII-Punycode-to-Unicode direction, and let the Punycode Converter apply Bootstring decoding to every label that carries the xn-- prefix while lowercasing ordinary ASCII labels and leaving them otherwise unchanged. Output is the readable Unicode spelling represented by the encoded form, ready for visual inspection before you click or copy. Each dot-separated segment is processed independently, so multi-label inputs round-trip exactly the way they came in — only the character set changes, not the label count or dot positions.
Reading an xn-- name in plain characters is useful whenever a domain appears in a log line, a certificate transparency report, an email header, or a payment reference and you want to confirm exactly which Unicode code points it stands for. The conversion is lossless and reversible, so re-encoding the result with the same Bootstring constants will reproduce the original ASCII label exactly.
What a Punycode Label Represents
Punycode was designed for a single purpose: let non-ASCII text survive a journey through the ASCII-only Domain Name System. A label is split into two parts — the basic code points that are already ASCII and the non-basic code points that need encoding — and the non-basic ones are delta-encoded with an adaptive bias that adjusts as values are processed. The xn-- prefix is a marker that the rest of the label is ACE-encoded and is consumed during decoding. The fixed constants used by the converter are base 36, tmin 1, tmax 26, skew 38, damp 700, initial bias 72, and initial code point 128, matching the values defined in RFC 3492.
Because the prefix is added or consumed only at label boundaries, multi-label domains are processed one segment at a time, separated by ASCII dots. Labels that already consist entirely of basic ASCII code points are lowercased and otherwise left alone; the prefix is never added to a label that did not contain any non-basic code point in the first place. This label-by-label convention is why a domain like example.xn--bcher-kva.org decodes to example.bücher.org rather than a single scrambled string, and why each segment can be inspected or copied independently after the round trip.
Run a Punycode to Unicode Conversion
- Paste only a domain name. The Punycode Converter does not accept a scheme, path, port, query, or fragment. Strip any https:// prefix, trailing slash, or path segment before pasting so the input matches a bare domain such as xn--bcher-kva.example or xn--fiqs8s.example.
- Choose the ASCII-Punycode-to-Unicode direction. This reverses encoding: it consumes the xn-- prefix on every qualifying label and runs Bootstring decoding against the remaining ASCII characters. Ordinary labels are lowercased and otherwise unchanged.
- Convert and inspect every label. Each dot-separated segment is processed independently. A label without the xn-- prefix is lowercased and otherwise unchanged, so the decoded domain preserves the same segment count and dot positions as the input.
- Copy the result with the dedicated button. The copy action places the converted domain on the clipboard without a scheme, trailing slash, or wrapping quotes, which is the form most APIs, certificate fields, and registry forms expect.
- Validate with the target registry or URL library. The conversion is reversible but not authoritative. Submit the ASCII label to the registrar that will host it, run it through a standards-compliant URL parser, or apply the registry's IDN policy before treating the result as accepted.
Reading the Result Without Falling for Look-Alikes
A successful decode only proves that the input was a well-formed Punycode label — it does not prove that the domain is trustworthy, that it resolves, or that it belongs to the organization its spelling seems to imitate. Characters from different writing systems can render almost identically: a Cyrillic а and a Latin a differ in code point but look the same at small sizes, and a Latin o is visually close to a Greek omicron. After decoding, compare the code points of every character that resembles a letter in a brand you recognize, and check the overall writing system rather than trusting visual inspection alone.
Decoded Unicode also says nothing about pronunciation, transliteration, or whether the name has been registered at all. Punycode is reversible text encoding, not a language translator or a directory lookup. For high-stakes decisions — clicking an unfamiliar link, wiring money to a domain in an email, or evaluating a certificate transparency entry — confirm the registrant and the registrar independently of what the decoded characters spell.
Raw Bootstring Output vs What Browsers Show
Browsers and many registries do not pass a label straight through Bootstring encoding and decoding. They run a sequence of normalization steps first, often summarized as UTS #46 mapping. This can change which code points end up in the label, fold certain characters together, or block characters that are forbidden in a given registry. The table below lists the main differences you can expect when comparing a raw RFC 3492 result with what a browser address bar ultimately displays.
| Step | Raw RFC 3492 only | With UTS #46 / browser mapping |
|---|---|---|
| Unicode normalization | None — code points are taken as written | Often NFC or NFKC applied before encoding |
| Forbidden or deviation characters | Decoded as plain Unicode code points | Mapped, blocked, or replaced per registry policy |
| Bidi and contextual rules | Not enforced | Contextual IDN rules checked before display |
| Final form shown to the user | Raw decoded Unicode | Browser may show a different spelling or a punycode fallback |
If a registrar rejects a result that the converter produces, follow that registry's IDN policy rather than editing characters by hand. The conversion here is intentionally narrow: it documents raw label conversion under the standard Bootstring constants and does not promise identical acceptance decisions to every consumer described in the WHATWG URL Standard or every registry's ruleset.
Limits and Inputs That Get Rejected
The converter is intentionally narrow so that it can give an unambiguous answer. Inputs that fall outside that scope are rejected with an explicit message rather than silently mangled:
- Empty labels — a domain with consecutive dots or a trailing dot.
- Malformed digits — a label that starts with xn-- but contains non-Bootstring characters in its encoded segment.
- Invalid Unicode scalar values — surrogate halves or out-of-range numbers produced by decoding.
- Inputs above 1,000 code points — anything larger is refused before decoding begins.
Full stops used as CJK punctuation are normalized to an ASCII dot before splitting, which prevents a visually identical input from accidentally producing an extra empty label. The implementation iterates Unicode code points rather than UTF-16 halves, so supplementary characters in CJK or emoji sequences stay intact across the round trip. Arithmetic overflow checks protect the delta multiplication and weight accumulation steps defined in RFC 3492, which is why very large inputs are rejected rather than silently corrupted.
Conversion typically changes a label's length, so DNS label length limits and registry policies still apply after conversion. A syntactically valid Unicode label can still be too long for the wire, blocked by the registry you plan to use, or already registered by someone else. Validate the final ASCII form with whichever authoritative consumer will accept it, and treat the converter as one reversible step in a larger workflow rather than a substitute for full URL parsing.