Punycode is the RFC 3492 standard that compresses Unicode code points into the 36-character ASCII alphabet so internationalized domain names fit the ASCII-only Domain Name System, and converting punycode to text means running that compression in reverse to read every code point inside an `xn--` label. The reversal is fully deterministic given the published Bootstring constants — base 36, tmin 1, tmax 26, skew 38, damp 700, initial bias 72 and initial code 128 — so every compliant decoder will produce the same Unicode output for the same input. A registered name such as `bücher.example` is stored on the wire as `xn--bcher-kva.example`, so reading what the name actually says requires a decoder that respects label boundaries, treats the dot as a separator rather than payload, and only applies Bootstring decoding to segments prefixed with `xn--`. Decoding exposes the exact code points inside an ASCII label; it does not check whether the domain is registered, who owns it, or whether the resulting string is the organization a reader expects.
What "convert punycode to text" means in DNS
In practical terms, converting punycode to text is the bookkeeping step that lets a person or a log pipeline see what an `xn--` form actually spells. The Domain Name System only carries ASCII bytes, so any non-ASCII label is published in Punycode and the original Unicode characters exist only as a recoverable state inside that ASCII form. Decoding does not register, lookup, or resolve the name — it just unpacks the variable-length delta stream that the encoder built, label by label, into a specific sequence of code points. Once that sequence is recovered, downstream code or a human reader can compare it against the spelling of a trusted domain and decide whether the name deserves further action.
| Constant | Value | Role during decoding |
|---|---|---|
| base | 36 | Size of the variable-length integer alphabet (a–z and 0–9). |
| tmin | 1 | Lower bound for the bias adaptation threshold. |
| tmax | 26 | Upper bound for the bias adaptation threshold. |
| skew | 38 | Adjustment applied to the bias after each decoded code point. |
| damp | 700 | Damping factor that keeps the bias stable across a label. |
| initial bias | 72 | Starting bias inside every newly opened label. |
| initial code | 128 | Lowest non-basic code point considered during decoding. |
Because these constants are fixed by RFC 3492, two decoders that honor them will always agree on what an `xn--` label says — though, as the next sections explain, a browser is not one of those decoders, since it typically maps and normalizes the Unicode string before encoding.
Decode a domain with the Punycode Converter
The Punycode Converter runs the RFC 3492 algorithm entirely in the browser, treats each label independently, and decodes only segments prefixed with `xn--` so ordinary ASCII segments pass through unchanged. The following ordered steps walk through a typical decode session.
- Paste only the domain name into the input box, without `https://`, a path, port, query or fragment — the converter accepts labels separated by ASCII full stops and does not parse URL structure.
- Select the ASCII-to-Unicode direction so each label beginning with `xn--` is treated as a Punycode payload while plain ASCII segments are copied through (and lowercased).
- Run the conversion and inspect the output label by label. Non-ASCII code points appear after any preserved basic characters; ASCII characters retain their original order at the front of the label.
- Copy the converted result and paste it back into the same tool in Unicode-to-ASCII mode as a round-trip check — both directions must agree for a well-formed input.
- Validate the final ASCII name with the registry, registrar or URL library that will consume it before any user-facing action is performed.
If any step rejects the input — empty labels between dots, malformed digits in the delta stream, code points that are not valid Unicode scalars, or an overall input above 1,000 code points — fix the ASCII label rather than guessing at substitutions. Bootstring decoding is not tolerant of typos: a single wrong character makes the rest of the delta stream misalign and the decoded Unicode stop meaning anything.
Read every decoded label and watch for look-alikes
A clean decode is the beginning of an inspection, not the end of one. Punycode tells you exactly which Unicode code points are hidden inside an ASCII label; it tells you nothing about how those characters are written, who owns the domain, or whether the spelling is meant to mimic a familiar brand. Decoded text such as "paypaI.com" — capital I instead of lowercase l — or a Cyrillic "а" standing in for a Latin "a" can still resolve to a working website that is not the organization a reader expects. Treat the decoded Unicode as a starting point for verification, not as proof of identity.
A practical inspection routine is to compare, label by label, what the decoder shows against the Unicode character at the same position in a name you already trust. If the strings do not match, do not visit the URL through a link. Run the same decoded string through the converter in the encoding direction and compare the result with the original ASCII label byte for byte; any difference signals that one of the two inputs was malformed. Because the implementation iterates over full Unicode code points rather than UTF-16 halves, supplementary characters above U+FFFF — for example ancient scripts, musical symbols, and most emoji — survive the decode intact, which is an asset for accuracy and a hazard if a different code point was expected in the same slot.
Why your browser may show different characters
A web browser rarely shows the raw RFC 3492 output. The WHATWG URL Standard defines an IDNA-aware processing pipeline in which the host string is mapped through Unicode normalization (usually NFKC), passed through the IDNA mapping table, and only then encoded as Punycode. Different browsers can ship slightly different versions of that table, which is why the same `xn--` label can decode to two visually distinct Unicode strings in two products. The Punycode Converter exposes the raw RFC 3492 result; the browser exposes the registry-friendly result; each is deterministic on its own, but they are not guaranteed to match.
This distinction matters when an internationalized domain is being registered. A registrar that follows UTS #46 may refuse an `xn--` form that decodes, under raw RFC 3492, to a perfectly valid Unicode label — usually because one or more code points are disallowed, confusable, or fold to a different character under NFKC. When a registrar rejects the ASCII output of this converter, follow that registry's published IDN policy rather than swapping characters blindly: the rejection typically points at a contextual rule (script mixing, blocking category, disallowed code point) that the raw algorithm cannot see on its own.
Limits, errors, and validating after decoding
The tool enforces a small set of hard limits so misuse surfaces as a clear error instead of a silent misread. Empty labels between dots are rejected, even though the DNS protocol technically tolerates them in some test contexts. Malformed digits inside the variable-length delta stream stop decoding so a corrupted label is not interpreted as a different Unicode string. Inputs above 1,000 code points are blocked to keep decoding bounded. Decoding is also restricted to labels that carry the `xn--` prefix; ordinary ASCII labels pass through lowercased but otherwise unchanged, which means a mixed domain such as `blog.xn--bcher-kva.example` decodes to `blog.bücher.example` rather than being stripped or rewritten. Unicode full stops that sometimes appear inside CJK text are normalized to an ASCII dot so the input still splits into the labels the algorithm expects.
Two further checks belong outside the tool. First, label length still applies: the 63-octet limit per DNS label and the 255-octet limit on a full domain are evaluated on the ASCII form, so a long Unicode label can be syntactically valid Punycode and yet overflow the wire limit. Second, registry policy still applies: even a syntactically clean `xn--` label can be a premium name, a reserved block, a script-confusion trap, or a synonym the registry has chosen to disable. Run the decoded string against the authoritative consumer of the name — the registrar's IDN policy, the certificate authority's SAN validator, or the application's URL parsing library — and let that consumer have the final word.