What is Punycode used for?

Punycode (RFC 3492) encodes internationalized domain names that contain non-ASCII characters into a limited ASCII form prefixed with xn--, so the existing DNS system can route them.

Does it convert whole domains?

Yes. Each dot-separated label is handled independently — Unicode labels gain the xn-- prefix when encoded, and xn-- labels are turned back into Unicode when decoded.

What does the xn-- prefix mean?

xn-- is the ACE (ASCII Compatible Encoding) prefix that marks a label as Punycode-encoded. Software sees the prefix and knows to decode the rest back into Unicode for display.

Why are internationalized domains encoded at all?

The DNS only handles a limited ASCII character set (letters, digits and hyphens). Punycode maps non-ASCII characters into that set so domains in any script can be stored and resolved by existing infrastructure.

Are ASCII-only labels changed?

No. A label with only standard ASCII characters needs no encoding and is left unchanged — only labels containing non-ASCII characters are converted to the xn-- form.

Why should I be cautious about Punycode domains?

Look-alike characters from other scripts can make a Punycode domain resemble a familiar brand (a homograph attack). Decoding a suspicious xn-- domain reveals the real characters behind it.

Is my domain sent anywhere?

No. The full Bootstring algorithm runs in your browser, so the domains you enter never leave your device.

What is the Punycode Converter?

Free Punycode converter for internationalized domain names. Turns Unicode domains like münchen.de into ASCII xn-- form and back, using the RFC 3492 Bootstring algorithm. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Punycode Converter — Gera Tools

Name: Punycode Converter
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Punycode converter for internationalized domains

Punycode is the encoding from RFC 3492 that lets internationalized domain names (IDNs) — those with accents or non-Latin scripts — work with the ASCII-only DNS. This tool converts a Unicode domain into its xn-- ASCII form and decodes it back, useful for developers, registrars and anyone inspecting an unfamiliar xn-- domain.

How it works

The converter implements the full Bootstring algorithm and processes a domain one dot-separated label at a time:

encode: each label with non-ASCII chars → "xn--" + bootstring encoding
decode: each "xn--" label → original Unicode characters
plain ASCII labels are left unchanged

Handling labels separately is why a multi-part domain round-trips cleanly.

Example

Encoding münchen.de:

münchen (contains ü) → xn—mnchen-3ya
de is ASCII → unchanged
Result: xn—mnchen-3ya.de

Decoding the same value returns münchen.de.

Direction	Input	Output
Encode	münchen.de	xn—mnchen-3ya.de
Decode	xn—mnchen-3ya.de	münchen.de
Encode	example.com	example.com (unchanged)

When you actually need this

The most common real-world use cases:

As a developer: You are building a user-registration flow that accepts email addresses or domains in any script. When you store or resolve the domain, you need the ASCII-compatible form. Calling a Punycode encoder on the domain portion before your DNS lookup ensures the resolver sees a valid hostname regardless of what the user typed.

Inspecting suspicious links: A phishing email may contain a link that looks like аррlе.com but uses Cyrillic characters that are visually identical to Latin letters. Pasting the domain here decodes it instantly and reveals the non-Latin characters — a technique called homograph attack detection.

Registrar workflows: Internationalized domain registrars display the Unicode form to users but submit the xn— form to the registry. If you are integrating with a registrar API, you may need to convert between the two depending on which form their endpoints expect.

Certificate debugging: TLS certificates for IDNs list the Punycode form in the Subject Alternative Name field. If a domain fails cert validation, checking whether you are comparing the Unicode and Punycode forms rather than the same representation is a useful first step.

Edge cases worth knowing

A label that is already pure ASCII — including example and com — passes through unchanged in both encode and decode directions.
Punycode is case-insensitive in the ASCII output; xn--mnchen-3ya and XN--MNCHEN-3YA are equivalent per DNS convention.
The algorithm encodes the label, not the separator dots. Each segment between dots is handled independently, which is why münchen.berlín.de encodes to xn--mnchen-3ya.xn--berln-kra.de.
Bidirectional text (Arabic, Hebrew) and mixed-script labels are valid Unicode but demand care: ICANN’s IDNA2008 protocol adds further restrictions beyond what RFC 3492 alone defines.

Everything runs locally in your browser.