To convert a URL to Punycode, you only encode the host portion of the address — the scheme, path, query string, and fragment are left alone because the DNS only stores ASCII labels for the domain. The Punycode Converter runs entirely in your browser using the RFC 3492 Bootstring algorithm, and it accepts a bare domain such as bücher.example or münchen.de, producing its ASCII equivalent xn--bcher-kva.example or xn--mnchen-3ya.de. Because a full URL like https://münchen.de/path?q=test still contains a scheme, a path, and a query, pasting it as-is will be rejected; the host has to be isolated first. Once the converted ASCII name is in hand, the result must be re-attached to its scheme and path before being handed to a registrar, a TLS certificate authority, or a URL parser. This split between host encoding and URL assembly is the most common stumbling block for anyone new to IDN work, and it is the reason URL-to-Punycode conversion is really two steps: extract, then encode.
Why URLs Need Punycode for the DNS Layer
The Domain Name System was originally defined to accept only the ASCII characters A through Z, digits 0 through 9, and the hyphen. That is the entire alphabet of the wire format — no accents, no Greek letters, no Han characters, no emoji. When the Internet community decided that people should be able to register domain names in their own scripts, the answer was not to extend DNS itself; it was to define a reversible encoding that squeezes Unicode code points into ASCII letters and hyphens. That encoding is Punycode, defined in RFC 3492.
Internationalized Domain Names in Applications (IDNA) layers a small set of rules on top of RFC 3492 so that a browser can take a host like münchen.de, encode each label separately, and hand the DNS resolver the ASCII form xn--mnchen-3ya.de. The resolver stores and queries that ASCII label without ever knowing what language the original spelling used. When the answer comes back, the browser decodes the label again so the user sees münchen.de in the address bar. Every step in that round trip works because RFC 3492 is a precise algorithm, not a language translation — and that is exactly what the Punycode Converter implements locally.
URL vs. Domain: What the Converter Actually Accepts
A URL is a structured string with a scheme, an authority (host plus optional port), a path, an optional query, and an optional fragment. Punycode only touches the host, and only at the label level inside that host. The Punycode Converter's documented scope is intentionally narrower than a full URL parser: it does not accept a scheme, path, port, query, or fragment, it does not percent-decode anything, it does not resolve DNS, test registration availability, or contact a registry. If you paste https://münchen.de into the input box, it will not work.
The tool expects a domain like münchen.de or xn--mnchen-3ya.de. Before any encoding happens, full stops are used to split the domain into labels, and Unicode full stops that look identical to ASCII dots in CJK text (such as U+3002) are normalized to an ASCII dot so the splitting stays predictable. Empty labels are rejected, as are inputs above 1,000 code points and any malformed Bootstring sequence. Anything that looks like a path, a query, or a fragment will not be parsed as a URL — it will be treated as malformed label data and refused. This is why percent-encoded URLs are not the right input here; percent encoding is a separate encoding system applied to paths and queries, and if you have a percent-encoded string you probably want a URL decoder instead.
Convert the Host Part of a URL to Punycode
This is the practical workflow when your starting point is a real URL rather than a bare domain.
- Copy the full URL you want to encode, for example https://münchen.de/produkte/neu.
- Strip everything that is not part of the host. Drop the https:// scheme, drop the path /produkte/neu, drop any query string or fragment. The remaining string — münchen.de — is what the converter will accept.
- Open the Punycode Converter and choose Unicode-to-ASCII for this direction. Use ASCII-Punycode-to-Unicode only if you are inspecting an xn-- name.
- Paste the bare host into the input field and run the conversion. The output will be xn--mnchen-3ya.de, with the xn-- prefix attached only to the label that contained non-ASCII characters and the .de label left as a plain ASCII string.
- Copy the result, then re-attach your original scheme and path so the final URL becomes https://xn--mnchen-3ya.de/produkte/neu. Hand that full string to a standards-compliant URL library, your registrar's IDN field, or your certificate authority's CN/SAN entry.
The same five-step shape works for any URL whose host contains non-ASCII characters, including Greek, Cyrillic, Hebrew, Arabic, CJK, and supplementary-plane symbols. Each label is processed independently, so a host like bücher.example.com produces xn--bcher-kva.example.com — two unchanged labels (example, com) flanking one encoded label (xn--bcher-kva). Re-attach your original scheme and path before handing the result to anything that expects a full URL.
How the RFC 3492 Bootstring Algorithm Encodes Labels
Inside the converter, each label is handled by the Bootstring algorithm with a fixed set of constants: base 36, tmin 1, tmax 26, skew 38, damp 700, initial bias 72, and initial code point 128. Existing ASCII characters in the label are copied through unchanged first. Non-ASCII code points are then encoded as variable-length deltas, with the bias parameter adapting after every value so that short labels and long labels stay efficient. The implementation iterates full Unicode code points rather than UTF-16 halves, which means supplementary characters stay intact instead of being split into a high surrogate and a low surrogate that would fail to round-trip. Arithmetic overflow checks protect both the delta multiplication and the weight accumulation so that long strings cannot wrap around silently.
| Input label | Direction | Output label | Notes |
|---|---|---|---|
| bücher | Unicode → ASCII | xn--bcher-kva | Documented example with the Latin umlaut, single label |
| mañana | Unicode → ASCII | xn--maana-pta | Spanish ñ plus a tilde, from the Latin-accent fixture |
| example | Unicode → ASCII | example | Pure-ASCII label, lowercased only, no xn-- prefix added |
| xn--maana-pta | ASCII → Unicode | mañana | Reverse direction, xn-- prefix consumed at the label boundary |
A label that contains no non-ASCII code points never receives the xn-- prefix — it is simply lowercased and left unchanged, which is why example.com stays as example.com and never becomes xn--example-com. Decode mode only runs Bootstring decoding on labels that begin with xn--; any other label is treated as plain ASCII. This narrow contract keeps the encoding reversible for every label the tool accepts, and any deviation — a leading scheme, a path slash, a percent-encoded byte — is rejected rather than guessed. Output is deterministic for the declared raw Punycode convention, and the copy button copies only the converted domain without a scheme or trailing slash.
Verify the Result Beyond Syntax
A successful conversion is not a guarantee that the resulting domain will be accepted everywhere or that it points to whoever you think it does. Production URL systems typically apply Unicode normalization, contextual rules, and UTS #46 mapping before they reach RFC 3492 encoding, which means a browser may show a slightly different ASCII form than the Punycode Converter does. The tool exposes raw label conversion; if your registrar rejects the output, follow that registry's IDN policy rather than editing characters by hand. Label length limits and registry policies still apply after conversion — a syntactically encoded label may be too long, reserved, blocked, or simply unavailable.
Security has to be handled separately. Punycode is not a language translator — decoding a label back to Unicode tells you the spelling, but it does not tell you how to pronounce the word or which organization owns the domain. Characters from different writing systems can look almost identical, which is exactly how homograph attacks work: аррӏе.com (using Cyrillic letters) can pass for apple.com to a hurried reader. Run the converted name through a standards-compliant URL library, check the WHOIS record, and confirm the writing system and owner before treating the result as trustworthy. The encoding step is reversible and exact; trust is a separate question that the encoding step cannot answer. Keep security filters and registry validation separate from this reversible encoding step.