Punycode / IDN Converter
A Punycode / IDN converter translates an internationalized domain name between the Unicode form a person reads, such as münchen.de or 例え.jp, and the ASCII xn-- form the DNS actually stores. Because the domain name system only understands a limited set of ASCII characters, every accented, Cyrillic, Arabic, or CJK label is encoded into a xn-- prefix plus a compact ASCII string defined by RFC 3492, and this tool converts that mapping in both directions, one dot-separated label at a time.
It is free and runs entirely in your browser. The full Punycode encode and decode algorithm executes locally in JavaScript with no library and no server call, so the domains you paste are never uploaded, which makes it safe for checking registrations, certificates, redirects, or possible look-alike spoofs.
例え.jp or bücher.de. Each dot-separated label is encoded only if it contains non-ASCII characters.
xn-- domain to read it back as Unicode. Labels without the xn-- prefix are passed through unchanged.
🔒 Private: everything runs in your browser. Nothing you paste is uploaded.
How to use the Punycode / IDN converter
Pick a direction, paste a domain, and read the converted form with a per-label breakdown. Only labels that need conversion change: non-ASCII labels gain an xn-- prefix when encoding, and only xn-- labels are decoded back to Unicode.
Encode Unicode to the xn-- form the DNS stores
Registrars, DNS zones, TLS certificates, and most logs record an internationalized domain in its ASCII-compatible encoding, so café.fr is stored as xn--caf-dma.fr. The encoder applies RFC 3492 to each dot-separated label independently, prefixes xn-- only to labels containing non-ASCII characters, and leaves pure-ASCII labels and the dots untouched. Use this direction when you need the exact string to enter into a registrar panel, a zone file, a certificate request, or a canonical redirect rule, where the human-readable spelling will not be accepted.
Decode xn-- back to readable Unicode
When a domain surfaces as xn--80ak6aa92e.com in analytics, an email header, a referrer, or a certificate, the decoder reverses the algorithm and returns the Unicode spelling so the label is legible again. Only labels beginning with xn-- are decoded; ordinary ASCII labels pass through unchanged. Reading the decoded form is the fastest way to recognise a homograph attack, where an address that displays as a familiar brand is actually built from look-alike characters in another script and resolves to an entirely different registered domain.
Why pixel-identical look-alikes matter for SEO and security
Two domains can look the same to a reader yet be completely different registrations, because Cyrillic, Greek, and Latin scripts share glyphs. Decoding the xn-- form exposes the real characters, which matters when auditing backlinks, vetting an acquisition, or investigating brand impersonation. Per-label conversion also keeps subdomains and the TLD correct, so shop.münchen.example encodes only the middle label. Confirm the ASCII form before you register, redirect, or trust an internationalized name, rather than relying on how a browser chooses to display it.
Punycode / IDN converter frequently asked questions
Q1What is Punycode and why do domains use it?
Punycode is the encoding defined in RFC 3492 that represents Unicode characters using only the ASCII letters, digits, and hyphen that the domain name system allows. An internationalized label such as münchen becomes the ASCII string mnchen-3ya, then gains the xn-- prefix to mark it as encoded. DNS, registrars, and certificates store this form, while browsers display the readable Unicode version back to the user.
Q2What does the xn-- prefix mean?
The xn-- prefix is the ACE, or ASCII-Compatible Encoding, marker that tells software the rest of the label is Punycode and must be decoded to reveal its Unicode characters. Only labels that originally contained non-ASCII characters carry it. A label without the prefix is plain ASCII and is left exactly as it is, which is why this converter changes only the labels that actually need encoding or decoding.
Q3Does this converter send my domains to a server?
No. The entire RFC 3492 encode and decode algorithm runs in your browser with client-side JavaScript and no external library or API call. Nothing you paste into either field is uploaded, logged, or stored, and the tool keeps working offline once the page has loaded. That makes it safe for checking unregistered names, internal hosts, certificate values, or domains you are investigating for abuse.
Q4Why does the encoded result look scrambled rather than transliterated?
Punycode is a mathematical encoding, not a phonetic transliteration, so it does not spell out how a word sounds. It records the ASCII characters of a label followed by compact codes describing where each non-ASCII character is inserted and which code point it is. The output looks arbitrary by design, yet it is fully reversible: decoding the same xn-- string always reproduces the exact original Unicode label.
Q5Can Punycode reveal a fake or look-alike domain?
Yes, and that is one of its most useful checks. A homograph attack uses look-alike characters from another script to build an address that displays like a trusted brand. Decoding the xn-- form shows the real characters and the true registered domain, while encoding a suspicious Unicode name exposes the ASCII string it actually resolves to. Comparing the two is a reliable way to spot impersonation before you click, register, or trust a name.
