Punycode Converter: The Complete Guide to IDN and xn-- Domain Encoding

The internet's addressing system was designed in an era when nobody imagined web addresses written in Thai, Chinese, Japanese, Arabic, or Cyrillic. Underneath everything, the Domain Name System (DNS) still accepts only plain ASCII: the letters a–z, digits, and hyphens. Yet billions of people navigate the web in scripts that ASCII cannot represent. Internationalized domain names (IDN) bridge that gap, allowing addresses like münchen.de, 日本.jp, or even the Thai government domain ราชการ.ไทย to exist in their native form.

Those friendly Unicode names cannot touch the wire directly, however. Before a lookup reaches DNS, each non-ASCII label is transformed into an ASCII-Compatible Encoding (ACE) using Punycode, the algorithm specified in RFC 3492. Encoded labels always start with the reserved prefix xn--, which tells resolvers, browsers, and mail servers "this label is Punycode — decode it before displaying." That is why münchen.de quietly becomes xn--mnchen-3ya.de and 日本.jp becomes xn--wgv71a119e.jp once it leaves your keyboard.

Our free Punycode Converter handles both directions of this transformation instantly, entirely in your browser. Whether you need a dependable IDN converter for day-to-day infrastructure work, a quick xn-- decoder to inspect a suspicious link, or simply want to understand how domain name encoding really works, this guide covers the concepts, the workflow, and the gotchas worth knowing.

Why Use the Punycode Converter?

• Register internationalized domains with confidence. Most registrars ask for the ACE form when you buy or configure an IDN. Converting unicode to punycode beforehand shows you exactly which ASCII string will end up in the zone.
• Unmask suspicious links in seconds. Phishing campaigns love lookalike domains. Pasting an xn-- address into the converter acts as an xn-- decoder, revealing the true human-readable script behind it.
• Debug DNS zones and mail servers. SPF, DKIM, MX records, and many legacy systems expect ACE labels. Converting punycode to unicode (and back) makes mismatched records obvious.
• Process whole domains, not fragments. The tool walks every dot-separated label independently, converting only the ones that need it and leaving pure ASCII labels untouched.
• Keep sensitive lookups private. Everything runs client-side. No server round-trips, no logs — the domain never leaves your machine.
• Trust standards-compliant output. The implementation follows the complete RFC 3492 algorithm, so results match what registrars, browsers, and resolvers produce.

Key Features

A few details deserve emphasis. The label-by-label behavior matters more than it sounds: in mail.日本.jp, only the middle label contains non-ASCII characters, so a correct IDNA implementation encodes just that one and passes mail through untouched. The built-in examples double as a learning aid — loading the Thai example shows a two-label domain where every label requires encoding, each emerging as its own xn-- label. And because invalid input stays unchanged rather than throwing an error, you can paste mixed or messy lists and pick out the lines that failed to transform.

How to Use

1. Open the tool. Head to the Punycode Converter — no account, installation, or setup required.
2. Paste your domain. Type or paste a full domain such as münchen.de into the input field.
3. Choose the direction. Stay on the Encode tab for unicode to punycode conversion, switch to Decode for punycode to unicode, or hit the Swap button to flip direction on the spot.
4. Review the per-label result. Check each converted label in the output panel; labels that could not be processed are shown unchanged so nothing silently breaks.
5. Copy the result. Click Copy and paste the ACE form into your registrar, zone file, or wherever it is needed.

Understanding Punycode and IDN

Why does any of this exist? DNS was standardized around RFC 1035-era assumptions: hostnames consist of ASCII letters, digits, and hyphens. Billions of dollars of infrastructure — resolvers, root servers, zone files, mail transport agents — assumes those rules. Rather than rebuild DNS, the IDNA (Internationalized Domain Names in Applications) architecture keeps DNS byte-for-byte ASCII and pushes all translation into the application layer. Non-ASCII names are permitted at the user level, but they must be represented as ACE strings before they reach the protocol.

That representation is Punycode. Defined in RFC 3492, it maps any Unicode string onto a compact alphabet of 36 characters (the lowercase letters and digits 0–9), i.e. base-36 arithmetic. The clever part is generalized variable-length integers: frequently predictable characters cost fewer bits, so typical labels stay short. The encoder also uses bias adaptation — starting from an initial bias of 72 and adjusting with constants like damp 700 and skew 38 — so that runs of similar characters compress efficiently no matter where they appear in the string.

The xn-- prefix is not part of Punycode itself; it is an IDNA marker glued onto the front. It reserves four characters that can never collide with a legitimate hand-typed hostname, letting resolvers distinguish "encoded label" from "weird but legal ASCII label."

Crucially, encoding happens per label, never across the whole domain. Dots are label separators, and each dot-separated piece is treated as an independent unit. Look at the Thai example: ราชการ.ไทย consists of two entirely non-ASCII labels, so both are encoded separately, yielding xn--12c2b4a3dxc.xn--o3cw4h — note the two xn-- markers. In contrast, www.münchen.de produces www.xn--mnchen-3ya.de: the first and third labels contain only ASCII, so they pass through unchanged while only the second gets wrapped. This rule is what lets Punycode coexist peacefully with millions of ordinary hostnames.

Practical Use Cases

Security Work: Exposing Homograph Domains

Homograph attacks register domains that look identical to famous brands in your browser's font — think a Cyrillic-based clone of a well-known company, rendered as an innocuous-looking xn-- label in raw links. Security teams routinely run every external URL's ACE labels through an xn-- decoder before clicking or approving them. If xn--80ak6aa92e decodes to something resembling a brand name in a different script, you have caught a phishing attempt before it happens. Converting both directions also helps document incidents, since reports should include the exact ACE form seen on the wire.

Web Admins: Verifying Thai, Japanese, and Chinese IDN Setups

If you operate sites under IDN-capable TLDs like .ไทย, .jp, or .cn, registration is only half the battle. Certificates, CDN configurations, HSTS entries, and analytics dashboards may each expect either the Unicode or the ACE form. A quick pass through the converter confirms that the punycode to unicode view of your certificate's SAN entry matches the domain customers actually type, and that unicode to punycode matches what sits in your DNS provider's dashboard. Mismatches here are a classic cause of certificate warnings that appear only for some visitors.

Debugging Email and DNS Records

Mail infrastructure is notoriously picky about IDN. Some SMTP implementations accept UTF-8 (EAI), others demand ACE; SPF macros and DKIM identifiers have their own expectations. When delivery fails inexplicably, decoding every xn-- label in the MX records, envelope addresses, and DKIM d= tags often reveals one component holding the wrong representation. The same trick untangles zone files exported from one provider and imported into another, where ACE and Unicode forms get mixed.

Curiosity: Learning How IDNA Works

If you have ever wondered what your browser does between your keystrokes and a DNS query, experimenting with real examples is the fastest way to internalize it. Try encoding a label with emoji, mixed scripts, or a very long Thai word, then decode the result back and confirm it round-trips perfectly. Watching base-36 output shift as you change a single character teaches more about variable-length integer coding than any diagram.

Best Practices

• Always verify the ACE form before registering. Confirm the exact xn-- string with your registrar — one wrong character means someone else can register the correct one.
• Lowercase domains before decoding. IDNA operations are case-insensitive at the protocol level, but normalizing to lowercase avoids confusing comparison results.
• Store ACE in DNS zone files. Unless your provider explicitly documents Unicode support, keep authoritative records in ACE form.
• Beware homograph attacks. Treat any unexpected xn-- label in a URL, QR code, or email as a prompt to decode before trusting it.
• Test both directions after changes. Round-trip every migration: encode, decode, compare. A perfect round-trip catches subtle normalization issues early.
• Keep display and storage separate. Show users the Unicode form; log, configure, and transmit the ACE form.

Try It Now

Ready to demystify an xn-- address or prepare an IDN for deployment? Open the free Punycode Converter, paste a domain, and get standards-compliant RFC 3492 output in milliseconds — privately, in your browser, with nothing logged anywhere.

Related Tools You Might Like

• URL Encoder — Percent-encode query strings and path segments so special characters survive transit intact.
• Base64 Encoder & Decoder — Encode or decode Base64 text and data inline for tokens, data URIs, and API payloads.
• ASCII/Binary Converter — Translate text into binary and hex representations and back for low-level debugging.

Happy decoding!