Punycode IDN Converter

Input mode:

Extraction is local and discards user-info, port, path, query, and fragment text.

Direction:

Auto reports the resolved direction in the summary and exports; an explicit choice bypasses detection.

Hostname or domain:

Examples: bücher.example, xn--bcher-kva.example, or—when extraction is selected—https://bücher.example/path.

Unicode normalization:

The neutral default preserves code points. Use NFKC only when compatibility folding is intentional and reviewed.

Preserve root dot:

This presentation option does not change label encoding or DNS length checks.

Form	Value	Use	Copy
{{ row.label }}	{{ row.value }}	{{ row.use }}

Label	Unicode	ASCII	Scripts	Review	Copy
{{ row.position }}	{{ row.unicode }}	{{ row.ascii }}	{{ row.scripts }}	{{ row.review }}

A domain name can be readable to a person and still need an ASCII form before it reaches DNS. Internationalized labels may contain characters such as ü, Greek letters, Arabic script, or CJK ideographs. Punycode represents those Unicode code points with letters, digits, and hyphens so the label can travel through ASCII-oriented systems.

The two forms serve different jobs. A Unicode label is easier to read and review. Its ASCII-compatible form begins with xn-- when Punycode encoding is needed. Conversion is reversible for a canonical Punycode label, but it is not a translation and does not prove that a domain exists, resolves, belongs to the expected owner, or is accepted by a registry or browser.

Label: One dot-separated part of a hostname, such as bücher or example.
U-label: A Unicode form intended for readable display under an IDNA policy.
A-label: An ASCII form beginning with xn-- that represents an internationalized label.
Normalization: A Unicode operation that can compose equivalent sequences or fold compatibility characters before encoding.

Normalization changes deserve deliberate review. NFC composes canonically equivalent sequences without broadly changing character meaning. NFKC also folds compatibility forms, so stylized or width-specific characters can become ordinary ones. The resulting hostname may look more familiar while no longer preserving the exact code points that were entered.

Visual similarity is a separate security problem. Cyrillic, Greek, and Latin characters can resemble one another, and right-to-left text can be hard to read beside punctuation or paths. A mixed-script warning is useful triage, not a complete confusable-character or bidirectional-text analysis.

DNS size rules apply to the ASCII form. Each label must fit within 63 octets, and an ordinary textual hostname without the final root dot must fit within 253 ASCII octets. Passing those limits says nothing about registry IDN tables, browser anti-spoofing display rules, certificate policy, or brand confusion.

How to Use This Tool:

Decide whether the source is already a bare hostname or is wrapped inside a URL, email address, or host-and-port value.

Choose Strict hostname for a bare domain or Extract host from URL, email, or port for wrapped text, then enter the hostname and correct any reported syntax problem.
Leave Direction on Auto detect for normal use. Auto decodes when any label begins with xn--; otherwise it prepares the ASCII form.
Use Unicode normalization only when the intended policy is known. Preserve the root dot only for an absolute DNS name that needs it.
Compare the Unicode and ASCII forms, then inspect every label marked Review before copying the selected result.

Interpreting Results:

Use the ASCII form for DNS records, allowlists, and other ASCII-only consumers. Keep the Unicode form beside it in tickets or approvals so reviewers can compare the user-visible name with the DNS-facing value.

Ready means the conversion completed within the local length and script checks. Review means at least one label mixes recognized scripts, the ASCII name exceeds a length rule, or normalization changed the source. Neither status certifies registration, resolution, browser display, or safety.

The label audit is more useful than the overall badge when one hostname has several labels. Check the exact Unicode spelling, the xn-- form, the 63-octet count, and the script summary for each label that will cross a security boundary.

Technical Details:

Punycode is the Bootstring algorithm defined by RFC 3492. ASCII code points already present in a label are copied into the basic portion, non-ASCII code points are represented as generalized variable-length integers, and an adaptive bias keeps nearby values compact. The xn-- prefix identifies the encoded payload in an internationalized hostname.

Transformation Core:

Internationalized hostname transformation stages
Stage	Rule	Boundary
Clean source	Fold ideographic, fullwidth, and halfwidth dot separators to `.`; strict mode otherwise requires a bare hostname.	Extraction accepts a URL, email host, or numeric port but rejects IP literals and ambiguous colon forms.
Normalize	Preserve code points, apply NFC, or apply NFKC before labels are converted.	A changed string adds a review warning.
Resolve direction	Auto chooses Unicode output when any source label begins with `xn--`; otherwise it chooses ASCII output.	An explicit direction bypasses this choice.
Decode labels	Remove `xn--`, decode the payload, then re-encode it.	The round trip must reproduce the same A-label apart from letter case.
Encode labels	Keep valid ASCII labels lowercase; Punycode-encode labels containing non-ASCII characters.	ASCII labels allow letters, digits, and hyphens, with no leading or trailing hyphen.
Audit	Measure the ASCII result and group Unicode characters into broad script categories.	Mixed recognized scripts and length failures require review.

Rule Core:

Punycode and DNS validation rules
Check	Passing rule	Meaning
Label syntax	Every ASCII label matches letters, digits, and hyphens and has no edge hyphen.	The local ASCII label is structurally acceptable to this converter.
Label length	ASCII label length is less than or equal to 63 octets.	The label fits the DNS label-size limit.
Hostname length	Joined ASCII labels are less than or equal to 253 octets, excluding a displayed trailing root dot.	The ordinary textual form fits the local DNS-length check.
Label count	One to 127 nonempty labels.	Empty labels and larger inputs are rejected before conversion.
A-label round trip	Decode, then re-encode to the same lowercase `xn--` label.	Rejects malformed or noncanonical Punycode payloads.
Script review	No label contains more than one recognized non-common script.	A pass is only a coarse script check, not a confusable-character verdict.

For bücher.example, only the first label needs encoding. The Unicode code points in bücher produce xn--bcher-kva, while example stays ASCII. The complete DNS-facing form is xn--bcher-kva.example; decoding that A-label returns the original readable form.

Input is limited to 1,024 characters. Preserving a trailing root dot changes only the displayed result; label conversion and the 253-octet hostname check use the core name without that dot.

Security and Limitations:

Conversion and script counting happen in the browser. Sharing or exporting a result can still disclose an internal or unreleased hostname.

The conversion applies RFC 3492 Punycode and local DNS length checks, not a full IDNA mapping, contextual-rule, bidirectional, or registry-policy validation.
Broad script categories do not detect every homoglyph, invisible character, combining-mark trick, or misleading right-to-left display.
Check high-risk names in the target registry, browser, certificate workflow, DNS resolver, and brand or allowlist review process.

References:

RFC 3492: Punycode, RFC Editor, March 2003.
RFC 5890: Internationalized Domain Names for Applications Definitions, RFC Editor, August 2010.
RFC 1035: Domain Names, RFC Editor, November 1987.
Unicode Technical Standard #39: Unicode Security Mechanisms, Unicode Consortium.