Punycode IDN Converter
Convert Unicode domains and xn-- Punycode labels in your browser, with DNS length checks, script warnings, and copy-ready forms.{{ summaryView.summaryTitle }}
| Section | Item | Value | Detail | Copy |
|---|---|---|---|---|
| {{ row.section }} | {{ row.item }} | {{ row.value }} | {{ row.detail }} |
| # | Label class | Input label | Unicode view | ASCII view | Len A/U | Review | Copy |
|---|---|---|---|---|---|---|---|
| {{ row.index }} |
{{ row.labelKind }}
{{ row.scriptProfile }}
|
{{ row.inputLabel }} | {{ row.unicodeLabel }} | {{ row.asciiLabel }} | {{ row.asciiLength }} / {{ row.unicodeLength }} |
{{ row.reviewStatus }}
{{ row.review }}
|
| Section | Item | Status | Value | Detail | Copy |
|---|---|---|---|---|---|
| {{ row.section }} | {{ row.item }} | {{ row.status }} | {{ row.value }} | {{ row.detail }} |
| Section | Item | Status | Value | Detail | Copy |
|---|---|---|---|---|---|
| {{ row.section }} | {{ row.item }} | {{ row.status }} | {{ row.value }} | {{ row.detail }} |
Introduction
A domain name may be reviewed by a person in one form and accepted by DNS software in another. Accented Latin letters, Arabic, Hebrew, Greek, Cyrillic, Han, Hangul, and other scripts can make a name readable to the intended audience, but the DNS wire format still has to fit ASCII label rules. That split is why bücher.example belongs in a human approval note while xn--bcher-kva.example may be the value used in a zone file, certificate request, registrar field, or allowlist.
Punycode is the IDNA encoding that lets those two views refer to the same label. It is not a translation of meaning and it does not prove that a domain exists. It is a reversible representation for eligible labels: the Unicode form is useful for display and review, while the xn-- form is the ASCII-compatible label used by DNS-oriented systems.
- U-label
- The Unicode label people expect to read, such as
bücher, when it is valid for IDNA use. - A-label
- The ASCII-compatible label beginning with
xn--, such asxn--bcher-kva, after a valid encode and round trip. - Plain LDH label
- An ordinary ASCII label made from letters, digits, and hyphens, such as
example.
The risky cases usually come from things that look small on screen. A label can mix scripts, use a character that resembles a Latin letter, include an alternate Unicode dot, or change under compatibility normalization. Right-to-left labels also need bidirectional text review because the visible order can be misread when the name appears beside punctuation, paths, ports, or surrounding text.
Successful encoding is still only one part of approval. A domain can convert cleanly and still be rejected by a registry, displayed as Punycode by a browser, denied by a certificate workflow, or confused with another brand. Names used for login, payments, email authentication, redirects, or production allowlists deserve a second check even when the encoded value is syntactically valid.
DNS length budgets apply to the ASCII representation, not to the number of visible Unicode characters. A short-looking native-script label can become a much longer A-label, and the whole hostname must still leave room for every dot-separated label. A final trailing dot is meaningful too because it marks an absolute fully qualified domain name rather than the host text many browser, registrar, and application fields expect.
Careful IDN handling means keeping the readable name, the DNS-ready name, and the review warnings together. The converted form can prepare a safe copy target, but ownership, availability, registry policy, browser display choice, and phishing risk still need checks outside a converter.
How to Use This Tool:
Start by deciding whether you are reviewing a clean hostname or extracting one from pasted text. Then choose the direction and read the review status before copying either form.
- Paste one value into Hostname or domain, such as
bücher.example,xn--bcher-kva.example, or a wrapped URL you need to inspect. - Keep Conversion direction on Auto detect for ordinary checks. Choose Unicode to Punycode when preparing a DNS-ready value, or Punycode to Unicode when checking what an A-label displays as.
- Set Input cleanup to match the paste. Use Strict hostname only for a clean host and Extract host from wrappers when the text includes a scheme, mailbox, port, path, query string, or surrounding punctuation.
Extraction reviews the host only. Ports, paths, and query strings are not part of the IDN label conversion.
- Open Advanced only when the review needs a preset, a Unicode normalization preview, trailing-dot preservation, or lowercase ASCII output for DNS-oriented copy.
- Read IDN Conversion first so the ASCII DNS form, Unicode display form, and optional normalized preview are side by side.
- Check Label Audit, Wire Review Ledger, and Paste Route Brief before copying. If the summary shows Block DNS paste, correct the hostname and rerun the check.
Do not bypass a blocked label by copying a neighboring row. A fake A-label, overlength label, empty label, symbol, or parser rejection needs a corrected hostname.
Interpreting Results:
Read the converted value together with the paste recommendation. The main output tells you what the selected direction produced, while the review status explains whether the hostname is ready for the intended destination, needs a human check, or should not be pasted into DNS-facing fields.
| Status | What it means | Usual next step |
|---|---|---|
| Ready to paste | Labels round-trip, DNS length checks pass, and the built-in review did not find blocking script, symbol, or parser issues. | Copy the ASCII DNS form for machine-facing fields and keep the Unicode form beside it in review notes. |
| Manual review before paste | The conversion succeeded, but mixed scripts, lookalike hints, normalization changes, right-to-left labels, or URL-host behavior need human approval. | Compare the label against the intended script policy, brand name, registry rule, or approval source before deployment. |
| Block DNS paste | A hard guardrail failed, such as an invalid xn-- label, reserved LDH pattern, bad label shape, symbol character, parser rejection, or length breach. |
Fix the input and rerun the conversion. Do not use a neighboring output row to bypass the failed label. |
Label Audit is where individual labels can be trusted or rejected. It distinguishes valid A-labels, ordinary NR-LDH labels, reserved R-LDH labels, fake A-labels, and syntax failures so one bad label does not hide inside an otherwise readable hostname.
Wire Review Ledger is the length and URL-host check. A lowercase-only URL-host difference is usually expected, but a mapping change or parser rejection should be reviewed before the hostname is used in links, logs, redirects, or request builders.
Paste Route Brief separates destinations. DNS, registrar, certificate, automation, ticket, and user-interface contexts do not always want the same string, so match the copy target to the destination instead of treating one converted value as universally safe.
Technical Details:
IDNA operates on labels, not on the whole hostname as an undivided string. Dots separate the labels, and each label has to satisfy its own syntax and length rules before the joined hostname can be useful to DNS-facing systems. Alternate Unicode dot separators are normalized to ordinary dots for splitting, which prevents a visually dotted hostname from being reviewed as one long label.
Punycode is a Bootstring encoding. In IDNA use, a valid encoded label carries the xn-- ACE prefix, decodes to a Unicode form, and re-encodes back to the same ASCII label apart from case. The prefix alone is not enough; a string can begin with xn-- and still be a fake A-label if the round trip fails.
Transformation Core:
| Stage | Rule | Why it matters |
|---|---|---|
| Input cleanup | Strict mode treats the pasted value as the host. Extract mode can pull the host from URL, email, host:port, path, or query text. | Prevents non-host text from being encoded as if it were part of a domain label. |
| Direction choice | Auto detect decodes when an xn-- label is present, otherwise it encodes to ASCII. Manual modes pin the branch. |
Keeps repeated change-window checks from switching direction because of an unexpected label. |
| Label conversion | Unicode labels become ASCII-compatible labels, and valid A-labels decode back to Unicode display text. | Separates the value meant for DNS from the value meant for human reading. |
| Round-trip review | The ASCII and Unicode forms are compared after converting back in the opposite direction. | Catches fake A-labels, failed conversion paths, and drift between the two representations. |
| Normalization preview | NFC, NFD, NFKC, or NFKD can be shown against the Unicode form without silently replacing the primary output. | Shows composed, decomposed, and compatibility-character differences before names are copied into logs or tickets. |
| URL-host comparison | The Unicode display form is serialized through a URL host parser and compared with the DNS row. | Reveals lowercase normalization, mapping changes, or parser rejection in browser-oriented workflows. |
Length Core:
DNS length checks are made on the ASCII form because that is the form that reaches DNS and many machine-facing fields. The visible Unicode length can be shorter, longer, or simply not comparable to the encoded label.
| Label class or signal | Meaning | Recommended action |
|---|---|---|
| A-label | A valid xn-- label that decodes and re-encodes cleanly. |
Use for DNS-facing fields if the remaining review checks pass. |
| NR-LDH label | An ordinary letters-digits-hyphen label that does not use the reserved third-and-fourth hyphen pattern. | Usually acceptable when length and hyphen placement checks pass. |
| R-LDH label | A reserved hyphen pattern that is not a valid A-label. | Correct it before treating the value as an IDN label. |
| Fake A-label | An xn-- string that fails the expected decode and re-encode test. |
Treat it as broken input and verify the intended Unicode source. |
| Mixed script or lookalike hint | Characters come from multiple writing systems, or the mix contains common Latin-lookalike characters. | Require human review, especially for login, payment, certificate, or allowlist use. |
| Right-to-left label | A label contains Arabic or Hebrew script and may need bidirectional text review. | Compare the Unicode display carefully and check the target registry or security policy. |
| Symbol, emoji, or leading combining mark | The label contains characters that are poor fits for ordinary IDNA publication or fail basic validity checks. | Do not publish until a registry-specific policy explicitly allows the form. |
Script and lookalike checks are practical warnings, not a full Unicode security review. They catch obvious mixed-script, right-to-left, symbol, emoji, leading-combining-mark, and normalization cases, but high-risk hostnames still need registry policy, browser display, certificate, and brand-confusion review.
Limitations and Privacy Notes:
The conversion is useful for preparing DNS-facing and display-facing values, but it does not settle ownership, availability, reputation, or registry acceptance.
- Conversion and review logic runs locally in the browser for the entered hostname; the value does not need to be submitted for a server-side conversion.
- No DNS, WHOIS, RDAP, certificate, Safe Browsing, or registrar availability lookup is performed.
- Registry IDN tables and label generation rules can be stricter than a general Punycode conversion.
- Browser address bars may choose Unicode display or Punycode display according to their own anti-spoofing rules.
- Script and lookalike warnings should be treated as review prompts, not as a complete phishing or homograph risk assessment.
Worked Examples:
Readable hostname for a DNS change
Enter bücher.example and choose Unicode to Punycode. The ASCII DNS form should be xn--bcher-kva.example. If the label audit and wire checks pass, that ASCII value is the safer copy target for DNS zones, registrar fields, certificate names, and automation.
A-label in an approval ticket
Enter xn--bcher-kva.example and choose Punycode to Unicode. The Unicode display form should be bücher.example. Keep both forms in the ticket so reviewers can compare the user-visible name with the DNS-ready label.
Wrapped URL before a redirect rule
For a pasted login URL containing bücher.example:8443/login?next=%2F, choose Extract host from wrappers. The reviewed host should be bücher.example; the port, path, and query string are left out because they are not domain labels.
Compatibility and blocked-paste review
A compatibility-styled hostname such as ℌ𝔢𝔩𝔩𝔬.com can look like ordinary Latin text in some fonts. Select an NFKC preview to see whether the display form changes, and treat a normalization difference, fake A-label, overlength label, symbol, or URL parser rejection as a reason to stop and correct the source hostname.
FAQ:
Should I copy the Unicode form or the Punycode form?
Use the ASCII DNS form for DNS zones, registrar host fields, certificate names, automation, and allowlists. Use the Unicode display form for human-facing notes, but keep the ASCII form nearby when accuracy matters.
Why does the tool warn about a domain that converts successfully?
A successful encode or decode only proves that a representation can be produced. Mixed scripts, lookalikes, right-to-left labels, length pressure, or parser differences can still make the hostname unsuitable for a specific destination.
Does Punycode prove that a domain exists?
No. Punycode conversion does not check DNS records, registration status, owner identity, reputation, certificate issuance, or registry availability.
Why can a URL parser output differ from the DNS row?
URL parsing can lowercase, map, or reject hosts according to browser-oriented rules. A lowercase-only difference is usually less serious than a mapping change or rejection, but URL-heavy workflows should still compare both rows.
What should I do with normalization preview differences?
Compare the raw Unicode display form with the selected normalization preview before using the name in logs, screenshots, review notes, or another system that normalizes text automatically.
Glossary:
- IDN
- An internationalized domain name, meaning a domain name that can contain Unicode labels for human-readable display.
- U-label
- The Unicode form of an IDNA-valid label.
- A-label
- The ASCII-compatible
xn--form of an IDNA-valid label. - LDH label
- A label made from letters, digits, and hyphens.
- NR-LDH label
- An ordinary LDH label that does not use the reserved hyphen pattern in positions three and four.
- R-LDH label
- A reserved LDH label. In IDNA use, only valid
xn--A-labels belong in that reserved space. - FQDN
- A fully qualified domain name, often shown with a trailing dot when an absolute DNS name is required.
References:
- RFC 5890: Internationalized Domain Names for Applications, Definitions and Document Framework, RFC Editor.
- RFC 3492: Punycode, RFC Editor.
- RFC 1035: Domain Names, RFC Editor.
- UTS #46: Unicode IDNA Compatibility Processing, Unicode Consortium.
- UTS #39: Unicode Security Mechanisms, Unicode Consortium.
- IDN Repository Procedures, IANA.
- ICANN IDN Guidelines, ICANN.