Punycode Converter

Punycode Converter - IDN to ASCII Domain Name Converter

A comprehensive Punycode converter tool for encoding and decoding Internationalized Domain Names (IDN). Convert Unicode domain names to ASCII-compatible Punycode format and vice versa. Essential for domain registration, email systems, DNS configuration, and international web development.

What is Punycode?

Punycode is a character encoding scheme used to represent Unicode characters (international characters) in ASCII format for domain names. It's part of the Internationalized Domain Names in Applications (IDNA) system.

**Key Features:**
• Converts Unicode domains to ASCII format
• All Punycode domains start with 'xn--' prefix
• Allows non-English characters in domain names
• Compatible with existing DNS infrastructure
• Standardized in RFC 3492

**How It Works:**
1. Separates ASCII characters from Unicode characters
2. Encodes Unicode characters using Base-36 encoding
3. Adds delimiter and positional information
4. Prepends 'xn--' prefix to indicate Punycode

**Example:**
• Unicode: münchen.de
• Punycode: xn--mnchen-3ya.de

The 'ü' character is encoded as '3ya' with delimiter positioning.

**Common Use Cases:**
• Internationalized domain names (IDN)
• Email addresses with Unicode characters
• DNS record configuration
• URL handling in browsers
• Domain name registration
• Internationalization (i18n) projects

**Supported Scripts:**
• Latin with diacritics (café.com)
• Chinese/Japanese/Korean (中国.cn)
• Arabic (مصر.eg)
• Cyrillic (россия.рф)
• Greek (ελλάδα.gr)
• Hebrew (ישראל.il)
• Thai, Devanagari, and many more

How to use the Punycode Converter?

**Encode Unicode to Punycode:**
1. Select 'Encode' mode (Unicode → Punycode)
2. Enter or paste your Unicode domain name
3. Click 'Process' button
4. Punycode result appears in output
5. Copy or download the result

**Decode Punycode to Unicode:**
1. Select 'Decode' mode (Punycode → Unicode)
2. Enter or paste the Punycode domain (xn--...)
3. Click 'Process' button
4. Unicode domain appears in output
5. Copy or download the result

**Input Examples:**

**For Encoding (Unicode input):**
• münchen.de
• 北京.中国
• café.com
• москва.рф
• ελλάδα.gr

**For Decoding (Punycode input):**
• xn--mnchen-3ya.de
• xn--1lq90i.xn--fiqs8s
• xn--caf-dma.com
• xn--80adxhks.xn--p1ai
• xn--hxajbheg2az3al.gr

**Tips:**
• Domain labels are processed separately (between dots)
• Only non-ASCII labels get converted to Punycode
• ASCII-only labels remain unchanged
• Use Swap button to quickly switch modes
• Case is preserved in ASCII portions

**Multiple Labels:**
You can convert entire domain names with multiple labels:
• Input: 日本.co.jp
• Output: xn--wgv71a.co.jp
• Note: Only '日本' is converted, '.co.jp' stays ASCII

Why is Punycode needed?

**The Problem:**
The original DNS (Domain Name System) was designed in the 1980s to only support ASCII characters (a-z, 0-9, hyphen). This meant:
• Only English-friendly domain names were possible
• Billions of non-English speakers couldn't use their native scripts
• International businesses faced limitations
• Email addresses were restricted to ASCII

**The Solution - Punycode:**
Punycode solves this by:
1. **Backward Compatibility:**
• Works with existing DNS infrastructure
• No changes needed to DNS servers
• All domain registrars can support it
• Compatible with all browsers and email clients

2. **Universal Access:**
• People can use domains in their native language
• Chinese users: 中国.cn instead of china.cn
• Arabic users: مصر.eg instead of egypt.eg
• Russian users: россия.рф instead of russia.ru

3. **Technical Requirements:**
• Email systems need ASCII format
• DNS queries must be ASCII
• HTTP headers require ASCII
• Certificate authorities need ASCII format

**Real-World Examples:**

**Before Punycode (ASCII only):**
• German: muenchen.de (awkward spelling)
• Chinese: beijing.cn (romanized, loses meaning)
• Arabic: misr.eg (transliteration)

**With Punycode (Native script):**
• German: münchen.de → xn--mnchen-3ya.de
• Chinese: 北京.cn → xn--1lq90i.cn
• Arabic: مصر.eg → xn--wgbh1c.eg

**Who Uses Punycode:**
• Domain registrars (GoDaddy, Namecheap)
• Email service providers (Gmail, Outlook)
• Web browsers (Chrome, Firefox, Safari)
• CDN providers (Cloudflare, Akamai)
• Certificate authorities (Let's Encrypt, DigiCert)
• Developers building international applications

**Security Consideration:**
Punycode can be exploited for homograph attacks where visually similar characters create deceptive domains:
• аpple.com (Cyrillic 'а') vs apple.com (Latin 'a')
• Browsers display Punycode (xn--...) for mixed-script domains to prevent this

What are IDN domains and how do they work?

**IDN (Internationalized Domain Names):**

IDN domains allow domain names to contain characters from non-ASCII scripts like Chinese, Arabic, Cyrillic, Hebrew, and many others.

**Architecture:**

**User Layer (What you see):**
• münchen.de
• 北京.中国
• москва.рф
• ελλάδα.gr

**Application Layer (IDNA Processing):**
• Browser/email client converts Unicode to Punycode
• xn--mnchen-3ya.de
• xn--1lq90i.xn--fiqs8s
• xn--80adxhks.xn--p1ai
• xn--hxajbheg2az3al.gr

**DNS Layer (ASCII only):**
• All lookups use Punycode format
• Standard DNS servers process requests
• No special infrastructure required

**How Browsers Handle IDN:**

1. **User Types:** café.fr
2. **Browser Converts:** xn--caf-dma.fr
3. **DNS Lookup:** Queries for xn--caf-dma.fr
4. **Server Responds:** IP address returned
5. **Browser Displays:** café.fr in address bar

**IDNA Versions:**

**IDNA2003 (Original):**
• First standardization
• Some character mapping issues
• Still widely deployed

**IDNA2008 (Current):**
• Improved Unicode handling
• Better security considerations
• Stricter validation rules
• Incompatible with IDNA2003 in some cases

**IDN TLDs (Top-Level Domains):**

Many countries now have native-script TLDs:
• .中国 (China) → .xn--fiqs8s
• .рф (Russia) → .xn--p1ai
• .مصر (Egypt) → .xn--wgbh1c
• .ελ (Greece) → .xn--qxam
• .ไทย (Thailand) → .xn--o3cw4h
• .சிங்கப்பூர் (Singapore) → .xn--clchc0ea0b2g2a9gcd

**Registration Process:**

1. **Choose Domain:** 北京.中国
2. **Registrar Converts:** xn--1lq90i.xn--fiqs8s
3. **Registry Checks:** Availability in Punycode format
4. **Registration:** Stored as Punycode in database
5. **User Sees:** Native script in browser/email

**Email with IDN:**

Email addresses can use IDN:
• User types: info@café.fr
• MTA converts: [email protected]
• SMTP sends: ASCII format
• Recipient sees: Native script

**Common Issues:**

**Browser Display:**
• Some browsers show Punycode for security
• Mixed scripts trigger Punycode display
• Helps prevent phishing (homograph attacks)

**Email Compatibility:**
• Not all email servers support IDN
• Some spam filters flag Punycode
• Best to test before deploying

**Character Restrictions:**
• Not all Unicode characters allowed
• Emoji generally not permitted
• Combining marks have restrictions
• Each registry sets its own policies

Punycode security considerations and best practices

**Security Risks:**

**1. Homograph Attacks:**

Visually similar characters from different scripts can create deceptive domains:

**Examples:**
• аррӏе.com (all-Cyrillic look-alike) → xn--80ak6aa92e.com
• apple.com (Latin) → apple.com
• Users can't distinguish visually

**Other Confusable Characters:**
• Latin 'a' vs Cyrillic 'а'
• Latin 'e' vs Cyrillic 'е'
• Latin 'o' vs Greek 'ο'
• Latin 'p' vs Cyrillic 'р'
• Number '0' vs Letter 'O'

**Real Attacks:**
• 2017: Xudong Zheng demonstrated apple.com homograph
• Used xn--80ak6aa92e.com (all-Cyrillic look-alikes)
• Visually identical to real Apple

**Browser Protections:**

Modern browsers implement protections:

**Mixed-Script Detection:**
• If a label mixes scripts (Latin + Cyrillic), show Punycode
• This tool flags mixed-script and confusable labels for you
• Prevents visual deception

**Whitelist Approach:**
• Some browsers allow single-script IDN
• 北京.中国 displays as Unicode (all Chinese)
• münchen.de displays as Unicode (Latin + diacritics)
• But mixed Chinese+Cyrillic shows Punycode

**Security Best Practices:**

**For Domain Owners:**

1. **Register Variations:**
• Register common homograph versions
• Example: If you own café.com, also get cafe.com
• Prevents attackers from registering similar domains

2. **Monitor Similar Domains:**
• Use domain monitoring services
• Alert on confusable registrations
• Take action on trademark violations

3. **Use HTTPS:**
• SSL/TLS certificates prevent most attacks
• Certificate shows real domain name
• Users can verify certificate

4. **Brand Protection:**
• Register in major scripts (Latin, Cyrillic, Chinese)
• Defensive registration strategy
• Redirect variants to main site

**For Developers:**

1. **Validation:**
• Validate Unicode normalization
• Check for mixed scripts
• Implement character restrictions
• Use IDNA2008 libraries

2. **Display:**
• Show Punycode for suspicious domains
• Highlight non-ASCII characters
• Provide visual indicators

3. **Email Handling:**
• Validate IDN email addresses
• Check for homograph patterns
• Consider blocking mixed scripts
• Log suspicious patterns

**For Users:**

1. **Verify URLs:**
• Check browser address bar
• Look for HTTPS and valid certificate
• Be wary of unexpected Punycode (xn--)
• Hover over links before clicking

2. **Bookmark Important Sites:**
• Don't rely on typing URLs
• Use bookmarks for banking, email
• Reduces risk of typos and homographs

3. **Enable Security Features:**
• Use browser security warnings
• Enable phishing protection
• Keep browser updated

**Testing Tools:**

1. **Confusables Detection:**
• Unicode confusables database
• Homograph detection scripts
• Visual similarity analysis

2. **IDNA Validation:**
• RFC 5891 compliance testing
• Unicode normalization checks
• Script mixing detection

**Regulatory Response:**

• ICANN requires registries to prevent confusable domains
• Many registries block mixed-script domains
• Certificate authorities perform stricter validation
• Some TLDs limit allowed character sets

**Recommended Tools:**
• Punycoder (validation and encoding)
• Unicode confusables checker
• IDNA conformance test suite
• Domain monitoring services (Brandfetch, DomainTools)

Why does my xn-- label differ from the registrar's?

Almost always because of normalization. IDNA2008 / UTS-46 require each label to be Unicode NFC-normalized and lowercased before Punycode encoding — a registrar or browser does this automatically.

**Two common traps:**

1. **Case:** 'MÜNCHEN.DE' must be lowercased to 'münchen.de' first, giving xn--mnchen-3ya.de. Encoding the uppercase form directly produces a different (invalid) label.

2. **Combining marks:** 'münchen' typed as base 'u' + combining diaeresis (U+0308) is NOT the same code-point sequence as the precomposed 'ü' (U+00FC). NFC composes them into one character, so both inputs yield the identical xn-- label.

This tool applies NFC normalization and lowercasing automatically on encode, so the xn-- output matches what a compliant registrar or browser computes. If you skip normalization elsewhere, your label will silently differ and fail to resolve.

What are the 63 and 253 octet DNS limits, and does my IDN exceed them?

DNS imposes two hard length limits, measured in octets (bytes) of the ASCII / Punycode form, not visible characters:

**63-octet label limit:** Each dot-separated label may be at most 63 octets. CJK and Arabic labels expand a lot once encoded — a 15-character Chinese label can easily blow past 63 bytes as xn--… and become unregistrable.

**253-octet FQDN limit:** The whole domain name (all labels plus the separating dots) must be at most 253 octets.

Because Punycode inflates non-ASCII text, a name that looks short in native script can exceed these caps. This tool runs a TextEncoder byte count on every encoded label and the full name after each conversion, showing a green badge when a label is within 63 octets and a red badge when it is over — so you know it is registrable before paying a registrar.

Key Features

• Bidirectional conversion (Unicode ↔ Punycode)
• NFC normalization (UTS-46)
• Roundtrip validation
• 63-octet label length check
• Mixed-script homograph warning
• Supplementary-plane (emoji / CJK Ext) support
• Support for all Unicode scripts
• Handles multi-label domains
• RFC 3492 compliant encoding
• Validates Punycode format
• Common examples reference table
• Copy to clipboard
• Download as text file
• Swap between encode/decode modes
• 100% client-side processing
• No data sent to server
• Works offline
• Dark mode support
• Full IDN compatibility
• Preserves domain structure