Punycode Converter

SEO specialists auditing international domains, developers debugging TLS certificate mismatches, and security reviewers triaging suspicious links all need the same thing: the exact ASCII hostname that DNS and certificates contain behind a Unicode name. This converter encodes Unicode labels to xn-- punycode and decodes them back, label by label, using a local RFC 3492 implementation. It also flags mixed-script labels and length overflows so lookalike domains are caught before they reach production config or a user's browser bar.

Domain or text (Unicode or xn--)

ASCII (punycode) form

—

Unicode form

—

Label breakdown

#	Original	ASCII	Unicode	Encoded
Paste a domain to see labels.

How the Converter Applies RFC 3492

The input is split on dots and the Unicode dot variants that IDNA accepts, then each label is processed on its own. Labels that already start with xn-- are decoded by reversing the Bootstring adaptive parameter algorithm: integers are read from the extended part, bias values are recomputed per code point, and the original Unicode string is rebuilt. Labels made only of ASCII characters pass through unchanged because DNS already accepts them.

Non-ASCII labels are lowercased with Unicode case folding, encoded to the Bootstring form, and prefixed with xn--. The tool then checks each result against the DNS limits of 63 characters per label and 253 characters per full hostname, and runs a script-mixing scan that compares Latin, Cyrillic, Greek, and Han ranges inside a single label. A mixed-script label is a strong homograph signal and is reported as a warning rather than a hard error, because some legitimate brands combine scripts.

Punycode vs. percent-encoding

Percent-encoding escapes bytes inside a URL path or query as %XX sequences and is reversible per character. Punycode compresses a whole Unicode label into printable ASCII and is reversible per label. Browsers show the Unicode hostname when IDNA policy allows it, but the TLS certificate and the DNS A record always contain the ASCII form. Paste either form here; the label table maps both directions.

What the warnings actually mean

A mixed-script warning fires when two or more of Latin, Cyrillic, Greek, or Han appear in one label, the pattern used by classic homograph registrations. Length warnings fire when encoding pushes a label past 63 characters, because punycode of long non-ASCII text grows quickly. An xn-- decode error means the characters after the prefix are not valid Bootstring data, which usually indicates a typo or a deliberately malformed link.

Before and after: normalizing an international domain

Before (mixed in config)

server_name münchen.example www.münchen.example;
canonical https://münchen.example/

After (ASCII everywhere in DNS/TLS)

server_name xn--mnchen-3ya.example www.xn--mnchen-3ya.example;
canonical https://xn--mnchen-3ya.example/

Use Cases

Developer	Production	Workflow
Fix an nginx server_name that fails to match an IDN request	Verify a TLS certificate SAN against the ASCII hostname	Audit newly registered IDN domains for homograph risk
Decode a suspicious xn-- link received in a support ticket	Keep canonical and hreflang tags on the DNS ASCII form	Convert customer-supplied Unicode domains before CRM import
Check mail server configs for SMTPUTF8 domain handling	Compare CDN edge hostnames with origin IDN settings	Document the ASCII alias next to the brand Unicode domain

Common Mistakes and Troubleshooting

The most frequent error is pasting a full URL with path and query into the field. Punycode applies to hostname labels only, so strip the scheme, path, and query first or the dot-splitting will treat path segments as labels. The second mistake is mixing the Unicode form in some config files and the xn-- form in others; nginx, HAProxy, and cloud load balancers compare the request Host header to the ASCII bytes, so a Unicode server_name never matches.

If a decoded label looks wrong, confirm the input was not double-encoded by a browser address bar that already converted it. If an xn-- label errors on decode, the payload may have been truncated when copied from a PDF or email client that soft-wrapped the line. Re-copy from the source without line breaks and decode again.

Best Practices for International Domains

Register the ASCII form as the source of truth and publish the Unicode form for humans in marketing material only. Every machine-facing artifact — sitemap entries, canonical tags, hreflang alternates, TLS certificates, nginx server_name, CDN origin hostnames — should use the xn-- form so crawlers and resolvers see one consistent identifier. Keep each label under 63 characters before encoding; if the encoded label exceeds the limit, shorten the brand string instead of relying on resolver-specific behavior.

Pair this converter with the URL encoder for percent-encoded paths, the hreflang tag generator for alternates, and the canonical URL checker before an international launch. When reviewing inbound links or email headers, decode the domain first and reject anything that mixes scripts inside a single label unless the brand is verified.

Punycode Converter FAQ

What is punycode and why does it exist?

Punycode is the encoding defined in RFC 3492 that maps Unicode text onto the limited ASCII character set allowed by DNS. Domain names on the classic DNS wire format accept only a-z, 0-9, and hyphens, so a name like münchen.example is rewritten as xn--mnchen-3ya.example before it is sent to a resolver. The xn-- prefix marks that the label carries encoded Unicode rather than literal ASCII text.

How is punycode different from percent-encoding in URLs?

Percent-encoding escapes individual bytes of a UTF-8 character as %XX sequences inside the path or query of a URL, and browsers usually display the decoded form. Punycode encodes an entire hostname label into a compact ASCII string with the xn-- prefix, and that ASCII form is what TLS certificates and DNS records actually contain. A URL encoder tool handles %XX escapes; this tool handles the xn-- label form used by IDN domains.

Why do phishing sites use punycode domains?

Attackers register names that decode to strings nearly identical to famous brands, for example a domain whose xn-- form decodes to аррӏе.com with Cyrillic letters. Browsers that display the Unicode form can hide the difference until the certificate details are inspected. Checking a suspicious link through this converter shows the exact ASCII hostname inside the certificate, which makes mixed-script and lookalike names obvious.

How do browsers decide whether to show Unicode or xn--?

Browsers apply IDNA processing (UTS #46 in modern engines) and only display the Unicode form when the label passes script and confusable checks. Labels that mix scripts, contain invisible characters, or match known confusable patterns are shown as raw punycode starting with xn--. Safari, Chrome, and Firefox differ slightly in which characters they allow to render as Unicode, so a label that looks safe in one browser may show as xn-- in another.

Does punycode affect SEO and international rankings?

Search engines crawl the ASCII form of a hostname and associate it with the registrant and language targeting signals of the site. Internationalized domains are supported, but hreflang and canonical tags must reference the same ASCII form that resolves in DNS. If a backlink or canonical tag points at the Unicode form while the sitemap lists the xn-- form, crawlers may treat them as inconsistent signals.

Can email addresses use punycode domains?

Yes. Internationalized email uses SMTPUTF8 or EAI extensions, and the domain part of the address follows the same IDNA rules as web domains. Many mail servers still expect ASCII-only domains, so converting the domain to its xn-- form with this tool before debugging mail routing avoids silent delivery failures.

Does the converter send my input to a server?

No. Encoding and decoding run entirely in the browser with a local RFC 3492 implementation. Nothing is uploaded, stored, or logged. You can disconnect from the network after loading the page and every conversion still works.