RFC 3492 Punycode conversion processes each domain label independently through the Bootstring algorithm, which is exactly why a single paste of a multi-label IDN domain handles every label at once and underpins any bulk Punycode workflow. The Punycode Converter treats each dot-separated segment as its own label, splits the input on full stops, normalizes CJK full stops to ASCII dots, then runs encode or decode on every label individually. Because the algorithm is local, deterministic and runs entirely in the browser, you can move through a long list of domains one after another, paste a single domain with many labels, or copy each converted result into a spreadsheet, DNS zone file or certificate request without any server round trip. The scope is intentionally narrower than a full URL parser: the tool does not accept schemes, paths, ports, queries or fragments, so bulk work here means bulk labels and bulk domains iterated through the same local converter, not bulk URL parsing.
Bulk Punycode Conversion: The Label-by-Label Approach
Internationalized domain names such as bücher.example or 例子.测试.de are not single strings — they are sequences of labels joined by dots, and each label is converted on its own. When the converter receives bücher.example, it splits on the dot, encodes the first label to xn--bcher-kva, leaves the second label as plain ASCII example, and reassembles the dotted output. That per-label behavior is what makes a multi-label domain convert as one bulk operation, and following the same label-by-label IDN conversion guide is the natural way to repeat it across a long list of domains.
Punycode is a representation, not a translation. The decoder reveals the Unicode spelling of an ASCII label, but it does not pronounce the word or confirm who owns it. The encoder shrinks Unicode code points into an ASCII-only form using variable-length deltas, but it does not check whether the result is registered, blocked or reserved. Keeping that boundary clear is what makes bulk conversion safe to script around: the same input always produces the same output, and every step that involves policy, registry or DNS lives outside the converter.
How to Convert Multi-Label Domains in Bulk
- Open the Punycode Converter and paste one domain name into the input field. Do not include https://, www., paths, ports or query strings — the tool accepts only the bare domain.
- Select the direction: Unicode-to-ASCII when the labels contain accented, CJK or other non-ASCII characters, or ASCII-Punycode-to-Unicode when the input begins with xn--.
- Click Convert and inspect each dot-separated label in the output. ASCII labels stay lowercased, non-ASCII labels receive the xn-- prefix on encode, and xn-- labels lose the prefix and reveal the original Unicode spelling on decode.
- Copy the converted result and paste it into your target system: a DNS zone file, a certificate signing request field, a registrar control panel, or a spreadsheet column. Each cell is independent because the algorithm is deterministic.
- Repeat for the next domain on your list. The local conversion has no rate limits, so bulk iteration is bounded only by typing speed and the 1,000 code-point per-domain ceiling.
RFC 3492 Constants Behind Deterministic Output
Bulk work depends on reproducibility. Two runs of the same label must produce the same ASCII string, and a Unicode label that encodes cleanly today must encode to the same bytes tomorrow. The converter fixes the RFC 3492 Bootstring constants so that the raw label conversion is fully deterministic and independent of any browser, locale or runtime guesswork:
| RFC 3492 constant | Fixed value |
|---|---|
| base | 36 |
| tmin | 1 |
| tmax | 26 |
| skew | 38 |
| damp | 700 |
| initial bias | 72 |
| initial code point | 128 |
With those constants fixed, the algorithm iterates Unicode code points rather than UTF-16 halves, so supplementary characters above U+FFFF stay intact. Existing ASCII characters in a label are copied first, then the non-basic code points are encoded as variable-length deltas and the bias adapts as values are processed. The bias adjustment is what keeps encoded labels compact: it shifts the threshold at which the encoding switches from one digit to two digits, so common scripts use shorter prefixes and rare scripts use longer ones. Arithmetic overflow checks protect the delta multiplication and weight accumulation, which matters when a single label contains dozens of accented or CJK characters. Verified fixtures cover Latin accents, Greek, CJK, symbols, one-label and multi-label domains in both directions, including bücher, mañana, 例子, 测试 and παράδειγμα. If you need to confirm that a bulk conversion matches a third-party library or DNS implementation, run the same label through both and compare the ASCII output character by character; raw RFC 3492 label conversion is the contract, not UTS #46 mapping or IDNA 2008.
Inputs the Bulk Converter Rejects
The converter is intentionally narrow, and bulk scripts should know exactly where that narrowness begins. The table below lists what the local engine accepts and what it rejects before any conversion runs.
| Input type | Outcome | Reason |
|---|---|---|
| Bare domain name | Accepted | Matches the documented scope |
| Full URL with scheme, path or query | Rejected | Tool is narrower than a browser URL parser |
| Domain with empty label (consecutive dots) | Rejected | Empty labels are invalid |
| Input above 1,000 code points | Rejected | Per-domain size limit |
| Malformed Punycode digits | Rejected | Invalid Bootstring input |
| Invalid Unicode scalar values | Rejected | Out-of-range code points |
Rejecting malformed input is what keeps bulk runs honest. A partial output with a corrupt label is worse than no output, because it can silently leak into a DNS zone file or certificate request and only fail later in production. The same boundary catches common bulk mistakes: pasting a URL with https:// prepended, accidentally concatenating two domains with no separator, or trailing whitespace that pushes the input past the 1,000 code-point ceiling. Each one is rejected without partial output, so bulk pipelines can branch on the outcome instead of receiving half-converted rows.
Validating Bulk Punycode Output Safely
A valid bulk conversion is not proof that a domain is safe to register, host or visit. Characters from different writing systems can look almost identical — a Cyrillic а and a Latin a are visually indistinguishable but encode to completely different Punycode labels. The converter exposes raw RFC 3492 label conversion only, so use it as a reversible encoding step and keep security filters, registry validation and homograph checks in a separate layer.
Production URL systems frequently apply Unicode normalization, contextual rules and UTS #46 mapping before encoding, and a browser may produce a different ASCII label for the same Unicode input if those rules disagree with raw RFC 3492. Treat the converter's output as the documented raw label form and let a standards-compliant URL library handle full application URLs. If a registrar rejects a converted result, follow that registry's IDN policy instead of silently altering characters — a syntactically valid label can still be too long, reserved, blocked or simply unavailable. For decoding, compare each label, writing system and organization carefully before clicking through; the Unicode spelling revealed by decode mode is informational, not a trust signal. Decoding exposes the spelling of an xn-- label but never tells you whether the domain belongs to the organization it visually resembles.
Related reading: XOR Encryption Online Bulk: Process Long UTF-8 Messages.