Punycode converter

Internationalized domain names need an ASCII-compatible encoding so DNS, certificates, and legacy resolvers can carry labels that include umlauts, accented letters, Cyrillic, Arabic, or CJK characters. Punycode (RFC 3492) is the Bootstring algorithm behind the familiar xn-- prefix used in IDNA A-labels. This capability encodes a single Unicode domain label into that ACE form, or decodes an ACE or raw Punycode body back to the original Unicode U-label, with a simple mode field and deterministic integer arithmetic. Invalid alphabet characters, empty xn-- bodies, lone surrogates, and multi-label strings with dots are rejected with a clear invalid input error instead of silent corruption.

Encode a Unicode domain label to Punycode ACE (xn--)

The engine lowercases the label in a locale-independent way, rejects empty strings, whitespace, control characters, and any embedded dots so you never accidentally treat a full multi-label hostname as one DNS label. Pure ASCII labels pass through unchanged without an xn-- prefix, matching IDNA practice for LDH names. When the label contains any non-ASCII code point, the engine runs the RFC 3492 Punycode encoder and prefixes the result with xn-- to produce the A-label used in DNS zone files, certificate SANs, and WHOIS displays.

The response includes result (the ACE or ASCII label), unicode (the folded U-label), punycode (the body without the xn-- prefix), ace true or false, mode encode, and method rfc3492 so tests can pin every field. Identical inputs always produce identical outputs because the path is pure arithmetic with no network, no random salt, and no wall clock. Use this path when you need a paste-safe A-label for a migration checklist, a zone-file line, or a support ticket that must survive systems that only accept ASCII hostnames.

Decode ACE or Punycode back to Unicode and handle invalid input

Set mode to decode and put an ACE label such as xn--mnchen-3ya or a raw Punycode body such as mnchen-3ya into text. The engine strips a leading xn-- prefix when present, validates that the body uses only the basic alphabet of letters, digits, and internal hyphens, then runs the RFC 3492 decoder to recover Unicode code points—including supplementary-plane characters represented with surrogate pairs in JavaScript strings.

Successful decode returns result and unicode as the U-label, punycode as the body, ace true when the input carried the xn-- prefix, mode decode, and method rfc3492. Prefer this capability when your search intent is a punycode converter for human-readable domain labels; full hostname splitting, public-suffix lookup, and live DNS resolution belong to other tools.

Using it in domain work and its limits

Call the free in-browser punycode converter for support playbooks, classroom demos, and one-off label checks without installing OpenSSL or language runtimes. A typical workflow encodes a Unicode brand label before writing an A-label into a zone template, then decodes ACE names copied from mail headers or certificate logs so operators can read the intended U-label. Another workflow verifies documentation samples still round-trip before a release.

DNS labels are capped at sixty-three octets in the ACE form, and this engine enforces that limit on encode so oversized international labels fail early rather than producing non-deployable strings. Authors shipping SDKs can map the result field into a copy button while unicode, punycode, and ace flags make OpenAPI examples self-explanatory for readers learning IDNA for the first time.