Punycode Domain Converter

What Punycode does for internationalized domains

The Domain Name System historically uses a restricted ASCII label syntax, while people use scripts and characters far beyond ASCII. Punycode, defined by RFC 3492, is a Bootstring algorithm that represents a sequence of Unicode code points with letters, digits, and hyphens. Internationalized domain name systems place the xn-- prefix before that payload to form an ASCII-compatible label, often called an A-label.

Punycode operates on one label at a time, not on dots or an entire URL. This page offers both a single-label mode and a complete-domain mode. Domain mode normalizes the common Unicode dot variants U+3002, U+FF0E, and U+FF61 to an ASCII period, preserves an optional final root dot, splits labels, and then encodes or decodes each label independently.

Punycode alone is not the whole modern IDNA stack. IDNA2008 and Unicode Technical Standard #46 define mapping, normalization, contextual, script, and validity rules that browsers and registries may apply. To avoid a new dependency and hidden network behavior, this implementation uses RFC 3492 plus a conservative local profile: letters, marks, numbers, and hyphens; lowercase ASCII output; no leading or trailing hyphen; 63-character encoded labels; and a 253-character encoded domain limit.

How to convert a Unicode domain or label

1. Choose Complete domain when the input contains dot-separated labels, or Single label when testing one label without dots.
2. Choose Encode for a human-readable Unicode name or Decode for an ASCII name containing xn-- labels.
3. Enter only the domain name, not a scheme, port, path, query, email address, or surrounding URL punctuation.
4. Review validation errors for empty labels, illegal characters, hyphen placement, non-canonical A-labels, or DNS length limits.
5. Use the result as an inspection aid. Confirm registry policy, Unicode normalization, script restrictions, and security rules with a production IDNA library before registration or trust decisions.

Punycode label and domain examples

These vectors show the RFC 3492 payload, the xn-- A-label prefix, complete domain handling, case normalization, and accepted Unicode dot variants.

Label syntax, case, dots, and validation

ASCII DNS labels are normalized to lowercase and may contain letters, digits, and hyphens. They cannot begin or end with a hyphen and cannot exceed 63 characters. A label beginning xn-- is decoded and re-encoded to ensure that it is canonical rather than merely alphabet-shaped.

Unicode labels in this implementation may contain Unicode letters, combining marks, numbers, and internal hyphens. Spaces, underscores, slashes, colons, at signs, emoji, and punctuation are rejected. That profile is intentionally conservative, but it is not a substitute for every contextual rule in IDNA2008 or UTS #46.

• Complete-domain mode accepts ASCII dots and three common Unicode full-stop variants.
• Empty internal labels such as a..b are invalid; one optional trailing root dot is preserved.
• Schemes such as https:// and paths such as /docs are not domain labels and are rejected.
• Encoded labels are limited to 63 ASCII characters and the complete encoded domain to 253 characters excluding a final root dot.
• Output A-labels are lowercase because DNS comparison is case-insensitive and canonical presentation is simpler.

How the RFC 3492 Bootstring algorithm works

The encoder first copies basic ASCII code points to the output. If any basic characters were copied, a hyphen delimiter separates them from the encoded suffix. The algorithm then tracks a current code point n, a delta, and an adaptive bias. It repeatedly finds the smallest unhandled code point, increases delta according to the number of already handled characters, and emits generalized variable-length integers in base 36.

Bias adaptation makes small code point differences compact while still handling large jumps. Digits zero through twenty-five map to a-z and digits twenty-six through thirty-five map to 0-9. The decoder reads those variable-length integers, updates n and the insertion position, and inserts each reconstructed code point into the output sequence rather than simply appending it.

This implementation guards JavaScript safe-integer arithmetic, rejects code points above U+10FFFF or in the surrogate range, verifies the final Unicode label against its conservative profile, and then re-encodes decoded xn-- labels to check canonical form. No DNS lookup occurs, so a structurally valid result does not imply that the domain exists, is registered, resolves, or is safe.

When Punycode conversion is useful

Punycode is mainly an interoperability and inspection layer. Users should normally see carefully validated Unicode names, while protocols, certificates, logs, and DNS software may expose A-labels.

Punycode errors and IDN security limits

A valid Punycode conversion is not a safety verdict. Unicode contains characters that resemble Latin letters, combining sequences with confusing rendering, and script combinations that browsers or registries may restrict. Homograph and confusable risks require policy, display heuristics, and user-interface protections beyond reversible encoding.

The opposite problem is overclaiming compatibility. A browser may apply UTS #46 mappings such as width conversion, normalization, or transitional treatment before Punycode. This dependency-free converter documents its narrower profile instead of pretending to reproduce every browser and registry decision.

• An underscore is common in some DNS service records but is not accepted as a hostname label here.
• Emoji and symbol-only labels are rejected by the conservative profile.
• An empty xn-- payload is invalid.
• A decoded label that does not re-encode to the same lowercase A-label is rejected as non-canonical.
• A domain that converts successfully may still be unavailable, unregistered, blocked, or visually deceptive.

Punycode compared with IDNA and URL encoding

Punycode is the compression-like algorithm for Unicode code points. IDNA is the larger domain-name framework that decides which labels are valid and how they are mapped. UTS #46 is a compatibility processing specification widely used by browsers and libraries. Treating those names as synonyms hides important policy differences.

URL percent-encoding operates on bytes in URL components and does not turn a Unicode hostname into DNS A-labels. A complete URL parser may perform IDNA on the host and percent-encoding on the path or query as separate steps.