Converting Punycode to ASCII (or back to Unicode) is essential for working with internationalized domain names (IDNs) in systems that only accept ASCII characters. Punycode, defined in RFC 3492, encodes Unicode characters into a limited ASCII subset, allowing domains like "bücher.example" to be represented as "xn--bcher-kva.example" in the Domain Name System (DNS). This conversion ensures compatibility with DNS infrastructure while preserving the original Unicode spelling for users. The process involves splitting the domain into labels, encoding or decoding each label individually, and adding or removing the "xn--" prefix for non-ASCII labels. For example, the domain "例子.测试" becomes "xn--fsqu00a.xn--0zwm56d" when encoded, and the tool reverses this transformation to restore the original Unicode characters. This is particularly useful for domain registrars, certificate authorities, and web developers who need to handle IDNs in environments that require ASCII-only input.
While Punycode enables global domain names, it does not guarantee security or availability. Decoding an "xn--" domain reveals its Unicode representation, but look-alike characters from different scripts (e.g., Cyrillic "а" vs. Latin "a") can still pose risks. Always verify the organization and writing system of a domain independently. The Punycode Converter tool simplifies this process by performing the conversion locally in your browser, without uploading data to external servers. It adheres strictly to RFC 3492, using fixed constants like base 36, tmin 1, and tmax 26 to ensure consistent results. However, it does not apply additional Unicode normalization or contextual IDN rules that some browsers or registries might use. This means the tool provides the raw Punycode conversion, which may need further validation depending on the target system.
When to Use Punycode Conversion
Punycode conversion is necessary in several scenarios where domain names must interact with ASCII-only systems. The most common use case is registering or managing an internationalized domain name (IDN) with a domain registrar or DNS provider. Many registries require IDNs to be submitted in their Punycode-encoded ASCII form, prefixed with "xn--". For example, if you own the domain "mañana.com", you would need to convert it to "xn--maana-pta.com" to configure DNS records or obtain an SSL certificate. Similarly, web developers working with APIs or databases that do not support Unicode must encode IDNs before storing or transmitting them. Another critical use case is inspecting suspicious domains: decoding an "xn--" domain reveals its Unicode representation, helping you identify potential homograph attacks or typosquatting attempts. Punycode is also used in email systems, where the local part of an address (before the "@") may contain non-ASCII characters that must be encoded for SMTP compatibility.
However, Punycode is not a universal solution for all text encoding needs. It is specifically designed for domain labels and does not handle URLs with paths, query parameters, or fragments. For example, converting "https://bücher.example/shop" requires encoding only the domain portion ("bücher.example" → "xn--bcher-kva.example"), while the rest of the URL remains unchanged. The Punycode Converter tool enforces this scope by rejecting inputs that include schemes, slashes, or other URL components. Additionally, Punycode does not translate between languages or scripts—it merely encodes Unicode code points into ASCII. A decoded domain like "xn--80ak6aa92e.com" becomes "apple.com" (with Cyrillic "a"), which looks identical to the Latin version but is a different domain. Always cross-check the decoded Unicode with the expected organization and script to avoid phishing risks.
How to Convert Punycode to ASCII or Unicode
- Open the Punycode Converter tool in your browser by visiting /encoding/punycode-converter/. The tool runs entirely locally, so no data is uploaded.
- Paste your domain name into the input field. The tool accepts only domain names (e.g., "bücher.example" or "xn--bcher-kva.example"), not full URLs or other text. Remove any scheme (http://), path (/shop), or query parameters (?id=123) before pasting.
- Select the conversion direction:
- Choose Unicode-to-ASCII if your input is a Unicode domain (e.g., "bücher.example") and you need the Punycode-encoded ASCII version (e.g., "xn--bcher-kva.example").
- Choose ASCII-Punycode-to-Unicode if your input starts with "xn--" (e.g., "xn--bcher-kva.example") and you want to decode it back to Unicode (e.g., "bücher.example").
- Click "Convert" to process the domain. The tool splits the domain into labels at each dot (e.g., "bücher" and "example"), encodes or decodes each label individually, and adds or removes the "xn--" prefix for non-ASCII labels. For example, "例子.测试" becomes "xn--fsqu00a.xn--0zwm56d" in ASCII mode.
- Inspect the result for accuracy. The tool displays each converted label separately, so you can verify that the encoding or decoding was applied correctly. Check for unexpected characters or look-alikes, especially if the domain contains symbols or mixed scripts.
- Copy the result using the "Copy" button. The tool copies only the converted domain (e.g., "xn--bcher-kva.example") without adding a scheme or trailing slash.
- Validate the result with your target system. For example:
- If you encoded a domain for DNS, submit the Punycode version to your registrar or DNS provider and confirm it is accepted.
- If you decoded a domain for inspection, cross-check the Unicode spelling with the expected organization and script to avoid homograph attacks.
Common Conversion Scenarios and Examples
| Input (Unicode) | Punycode (ASCII) | Use Case |
|---|---|---|
| bücher.example | xn--bcher-kva.example | Registering a German domain with a registrar that requires ASCII input. |
| mañana.com | xn--maana-pta.com | Configuring DNS records for a Spanish-language website. |
| 例子.测试 | xn--fsqu00a.xn--0zwm56d | Encoding a Chinese domain for use in a certificate signing request (CSR). |
| παράδειγμα.δοκιμή | xn--hxajbheg2az3al.xn--jxalpdlp | Inspecting a Greek domain received in an email for phishing risks. |
| ☃-⌘.example | xn----dqo34k.example | Testing how symbols and emoji are encoded in IDNs (note: many registries block symbols). |
The table above shows how different scripts and symbols are converted between Unicode and Punycode. Note that while the tool supports all Unicode characters, some registries may reject domains containing symbols, emoji, or mixed scripts. Always check the IDN policy of your registrar before relying on a converted domain. For example, the snowman-and-command-symbol domain ("☃-⌘.example") encodes to "xn----dqo34k.example", but many registries would block such a domain due to its non-standard characters. The Punycode Converter tool performs the encoding without enforcing registry-specific rules, so validation is your responsibility.
Limitations and Security Considerations
The Punycode Converter tool is designed for label-by-label conversion of domain names, not full URLs or arbitrary text. It enforces several limits to ensure RFC 3492 compliance and prevent misuse. First, the tool rejects inputs that include a scheme (http://), path (/shop), port (:8080), query (?id=123), or fragment (#section). These components are not part of the domain and cannot be processed by Punycode. Second, the tool normalizes Unicode full stops (used in some CJK text) to ASCII dots before splitting labels, but it does not perform full Unicode normalization (e.g., NFC or NFKC). This means the tool may produce different results than browsers or registries that apply additional normalization steps. Third, the tool rejects malformed inputs, such as empty labels, invalid Unicode scalar values, or encoded sequences that exceed 1,000 code points. These safeguards prevent processing errors but may cause the tool to fail on domains that other systems accept.
Security is a critical concern when working with Punycode. Decoding an "xn--" domain reveals its Unicode representation, but it does not guarantee the domain is safe or legitimate. Homograph attacks exploit look-alike characters from different scripts to create domains that appear identical to trusted ones. For example, "аррӏе.com" (Cyrillic) decodes to the same Punycode as "apple.com" (Latin), but it is a distinct domain controlled by a different entity. The Punycode Converter tool does not detect or warn about such attacks—it only performs the reversible encoding step. Always verify the organization and script of a decoded domain independently. For example, if you receive an email linking to "xn--80ak6aa92e.com", decode it to "apple.com" (Cyrillic) and recognize it as a phishing attempt. Additionally, some registries apply contextual rules or blocklists to prevent abusive domains, so a syntactically valid Punycode domain may still be rejected during registration. Always validate the final ASCII name with the authoritative consumer (e.g., registrar, browser, or certificate authority) before relying on it.
For developers, the tool's implementation details are worth noting. It processes Unicode code points rather than UTF-16 halves, ensuring supplementary characters (e.g., emoji) remain intact. The Bootstring algorithm uses fixed RFC 3492 constants (base 36, tmin 1, tmax 26, etc.) to encode non-ASCII code points as variable-length deltas, with an adaptive bias that adjusts during processing. The tool includes arithmetic overflow checks to protect against invalid inputs, and its output is deterministic for the declared raw Punycode convention. However, it does not replicate the UTS #46 mapping or contextual rules used by browsers, so production systems may need additional preprocessing. If a registrar rejects a converted domain, follow their IDN policy rather than altering characters blindly. For example, some registries require domains to use a specific script or block certain characters, even if they are valid in Punycode.