Converting an IDN domain to Punycode rewrites every non-ASCII label into an ASCII string prefixed with xn-- so the Domain Name System, TLS certificate fields, and other ASCII-only infrastructure can store and route the name. A domain such as bücher.example becomes xn--bcher-kva.example, while a label that is already pure ASCII, like example, is left alone and just lowercased. The conversion is local, deterministic, and reversible: pasting xn--bcher-kva.example back into decode mode returns bücher.example. That round-trip property is what lets registries, browsers, and certificate authorities treat the encoded form as the canonical network name while still letting humans see and type the original spelling. The Punycode Converter performs that label-by-label translation in the browser using the RFC 3492 Bootstring algorithm, without contacting a registry, performing DNS lookups, or applying Unicode normalization. Because each label is handled on its own, you can paste a single-label internationalized string, a fully qualified domain, or a mix of scripts in one pass, and the tool will report which labels were converted and which were simply passed through unchanged.
Why IDN Domains Need Punycode
Internationalized Domain Names let registrants use scripts far beyond the Latin alphabet, but the underlying DNS protocol only knows about A–Z, 0–9, and hyphens. A domain such as παράδειγμα.cy or 例子.测试 cannot literally exist in a zone file, a TLS certificate's Common Name field, or most command-line resolvers. RFC 3492 closes that gap by defining a reversible encoding, called Punycode, that compresses any sequence of Unicode code points into a basic ASCII string. Each affected label receives the xn-- prefix so consumers can tell at a glance that decoding is required to recover the original spelling. Without this step, no name server would accept the entry, no certificate authority would sign it, and almost any tool that parses a hostname would refuse to look it up.
The encoding is deliberately narrow. It only handles label contents and never interprets the surrounding URL, so the same algorithm can encode a top-level domain, a fully qualified domain, or a single bare label. That separation is also why RFC 3492 has remained the reference for nearly two decades: every layer above it can apply its own normalization and policy without breaking compatibility with the ASCII form stored on the wire.
How to Convert an IDN Domain to Punycode
The steps below cover the entire workflow a typical user runs in the Punycode Converter, from pasting the domain to validating the output with the system that will ultimately store or display it.
- Paste only a domain name into the input field. Use Unicode-to-ASCII when the input contains letters such as ü, é, π, 中, or any non-ASCII code point. Use ASCII-Punycode-to-Unicode when the input already starts with xn-- in one or more labels. Do not include a scheme, path, port, query, or fragment.
- Choose the conversion direction. Encoding adds xn-- to labels that contain non-ASCII code points. Decoding strips that prefix from any label that carries it and leaves ordinary ASCII labels untouched.
- Convert and inspect every label. The output preserves each label boundary, so multi-label domains stay clearly separated. In encoding mode, an ASCII-only label is just lowercased; only labels with non-ASCII code points gain the xn-- prefix.
- Copy the result. The copy button returns only the converted domain without a scheme or trailing slash, ready to paste into a DNS provider, a certificate signing request, or a server configuration line.
- Validate downstream. Re-decode the result with the same tool to confirm the original Unicode spelling comes back byte-for-byte, then check the name against the target registry's IDN policy or a standards-compliant URL library before relying on it.
Worked example, drawn from the documented test fixtures: pasting bücher.example into encode mode returns xn--bcher-kva.example. Pasting that result back into decode mode returns bücher.example. The single non-ASCII label picks up the xn-- prefix while the example label is unchanged.
What the Converter Actually Does to Each Label
Each label is processed independently with the RFC 3492 Bootstring constants fixed at the values shown below. Existing ASCII characters are copied through first, and non-ASCII values are encoded as variable-length deltas. The algorithm iterates Unicode code points rather than UTF-16 halves, so supplementary characters such as emoji or rare CJK extensions remain intact. Arithmetic overflow checks protect the delta multiplication and weight accumulation steps, and full stops split the domain into labels without becoming part of the encoded payload. Unicode full stops commonly used in CJK text are normalized to an ASCII dot before splitting.
| Constant | Fixed value | Role in the encoding |
|---|---|---|
| base | 36 | Numeric base used for digit encoding |
| tmin | 1 | Lower threshold for bias adaptation |
| tmax | 26 | Upper threshold for bias adaptation |
| skew | 38 | Skew constant applied during bias update |
| damp | 700 | Damping factor on the first pass |
| initial bias | 72 | Starting bias value |
| initial code point | 128 | First non-basic code point considered |
Because the constants are fixed and the input is split before processing, the output is deterministic for the declared raw Punycode convention. Two different runs of the same input always produce the same xn-- string, which matters when comparing results across systems. Eight external test fixtures cover Latin accents, Greek, CJK, symbols, one-label and multi-label domains, with negative cases covering empty labels and incomplete encoded sequences.
Round-Trip Validation and Look-Alike Risks
A Punycode conversion is reversible in principle, but the round-trip is only meaningful if the spelling you expected is the spelling you get back. Paste xn--bcher-kva.example into the decoder and confirm that bücher.example reappears byte-for-byte. If a different character set appears, the original input was malformed or used pre-normalized forms the raw algorithm does not recognize. The tool surfaces the most common failure modes as outright errors: empty labels, malformed Bootstring digits, invalid Unicode scalar values, and inputs above 1,000 code points are rejected, so a wrong answer never silently slips through.
Look-alike risk is a separate concern that the encoding cannot solve on its own. Characters from different writing systems can render nearly identically; for instance, Cyrillic а and Latin a share most fonts. Punycode is not a language translator. Decoding exposes the Unicode spelling represented by an ASCII label but does not tell you how to pronounce it or whether it belongs to the organization it resembles. Treat the encoded string as opaque, verify the writing system of each decoded label independently, and let security filters and registry validation handle homograph defenses separately from this reversible encoding step.
When Browser Output and This Tool Disagree
The Punycode Converter exposes raw RFC 3492 label conversion, which is intentionally narrower than a complete browser URL parser. Production browsers usually apply Unicode normalization and the UTS #46 mapping table before Bootstring encoding, so a domain typed into an address bar can produce an xn-- string that differs from what a raw encoder produces for the same Unicode input. The WHATWG URL Standard documents that mapping layer in detail and explains the contextual rules that can change a code point's case or merge a compatibility character before encoding.
When the two outputs disagree, neither side is necessarily wrong. The registry or application that ultimately stores the name will follow its own IDN policy, and you should match that policy rather than alter characters blindly. If a registrar rejects a result, follow the registry's documented IDN rules instead of editing the Unicode form by hand, because label length limits, reserved blocks, and restricted scripts are enforced after the encoding step, not by it. For DNS-specific guidance on placing the encoded name into a zone file or certificate request, see Convert a Domain to Punycode for DNS Compatibility.
Limits and What Comes After Conversion
The converter accepts only a domain name. It will not parse a scheme, path, port, query, or fragment, perform percent decoding, resolve DNS, test registration availability, or contact a registry. Inputs that look like full URLs, such as https://bücher.example/path, must be trimmed to the host portion first. Empty labels, malformed digits in the Bootstring payload, and inputs above 1,000 code points are rejected. Label length limits and registry policies still apply after conversion: a syntactically encoded label may be too long, reserved, blocked, or simply unavailable, so validate the final ASCII name with the authoritative consumer before publishing it.
| Concern | Handled by this tool | Handled downstream |
|---|---|---|
| RFC 3492 Bootstring encoding | Yes | — |
| UTS #46 Unicode mapping | No | Browser or URL library |
| IDN policy and restricted scripts | No | Registry |
| Label length limits | No | Registry |
| DNS registration availability | No | Registrar |
| Homograph defense | No | Application security |
Keeping those responsibilities split is what lets the conversion stay small, fast, and easy to audit. The encoding step produces a deterministic ASCII name; every policy decision about whether that name may be registered, signed, or routed lives in the system that consumes the result.