URL Punycode & Internationalized Domain (IDN) Converter
Convert Unicode internationalized domain names (IDNs) and URLs into ASCII Punycode (xn--) and vice-versa in real-time according to RFC 3492 and RFC 5891.
ASCII (ACE)
Full URL
13
US-ASCII
DNS Provisioning Tip: When registering Internationalized Domain Names (IDNs)—such as .de, .ελ, or .рф—with DNS registrars (such as Cloudflare, AWS Route 53, or GR-Hostmaster) or configuring SSL certificates via Let's Encrypt / ACME, always submit the ASCII Punycode form (xn--...) to avoid zone-file parse rejections.
The Architecture of RFC 3492: How Punycode Bridges DNS and Global Scripts
The Internet's Domain Name System (DNS) was architected around the strict LDH convention (Letters ‘a-z’, Digits ‘0-9’, and Hyphen ‘-’) as defined in RFC 1034 and RFC 1035. As the web expanded globally, non-Latin alphabets—including Latin with diacritics, Greek, Cyrillic, Devanagari, Hebrew, Arabic, and Chinese-Japanese-Korean (CJK) logographs—required native web address representation. Punycode (RFC 3492) and IDNA (Internationalizing Domain Names in Applications, RFC 5890-5894) solved this dilemma without re-engineering the global DNS root server network.
Bootstring Algorithm
Punycode is an instance of the Bootstring algorithm. It separates basic ASCII code points from extended Unicode code points, rendering the basic ones verbatim and encoding non-ASCII delta offsets using generalized variable-length integers.
ACE Prefix (xn--)
Every internationalized label converted to Punycode is prepended with xn--. This reserved string alerts DNS resolvers and HTTP clients that the subsequent characters represent encoded Unicode.
Client-Side Resolution
All encoding and decoding occurs at the application layer. When a user navigates to an IDN in Chrome, Firefox, or Safari, the browser converts the label to ASCII Punycode prior to dispatching UDP/TCP DNS queries on port 53.
Real-World IDN to Punycode Conversion Matrix
| Language / Script | Unicode IDN Label | Punycode ACE Host | Primary Use-Case |
|---|---|---|---|
| German (Latin Umlaut) | münchen.de | xn--mnchen-3ya.de | Municipal and localized commercial portals in DACH regions. |
| French (Acute Accent) | café.com | xn--caf-dma.com | Branded hospitality and restaurant web domains. |
| Greek (ccTLD .ελ) | ελλάδα.ελ | xn--qxaa.xn--qxam | National Greek Top-Level Domain and regional public institutions. |
| Greek (Modern with Tonos) | αθήνα.gr | xn--hxajb6cu4a.gr | Hellenic commercial, cultural, and municipal portals under .gr. |
| Russian (Cyrillic ccTLD) | россия.рф | xn--h1alffa9f.xn--p1ai | National Russian federation top-level domain namespace. |
| Japanese (Kanji & Kana) | ジェイピー.jp | xn--hckqz9bcg.jp | Domestic Japanese brand names and corporate addresses. |
| Chinese (Simplified) | 网络.cn | xn--io0a7i.cn | Mainland Chinese enterprise and educational networks. |
Cybersecurity Implications: IDN Homograph Phishing & Browser Defenses
While IDNs foster inclusive Internet accessibility, they introduce substantial attack surfaces through homoglyphs—characters from diverse scripts that look identical or near-identical to human eyes. Understanding how browsers display Punycode is vital for cybersecurity analysts and webmasters.
The Homograph Threat Model
An attacker could register the domain аpple.com using the Cyrillic small letter ‘а’ (U+0430) or substitute Greek omicron ‘ο’ (U+03BF) in place of Latin ‘o’ (U+006F). To end-users, the address appears visually identical. However, the true underlying DNS query resolves to an entirely different Punycode string (e.g. xn--...), allowing malicious operators to conduct deceptive credential harvesting.
Browser Anti-Spoofing Rules
Modern browsers (Chromium, Firefox, Safari) implement Unicode Consortium Technical Report #36 security profiles. If a domain mixes incompatible scripts (e.g., Latin mixed with Cyrillic or Greek in a single label) or belongs to an unvetted TLD without rigorous IDN policies, the browser automatically displays the raw xn--... string in the address bar.
| Specification Dimension | IDNA2003 (Legacy) | IDNA2008 (Current RFC Standard) |
|---|---|---|
| Underlying RFCs | RFC 3490, RFC 3491, RFC 3492 | RFC 5890, RFC 5891, RFC 5892, RFC 5893 |
| German Sharp S (ß) | Mapped to “ss” (lossy conversion) | Allowed natively; distinct Punycode output |
| Greek Final Sigma (ς) | Mapped to small sigma (σ) | Preserved without algorithmic rewriting |
| Unicode Base Dependency | Hard-coded to Unicode 3.2 | Dynamic; tracks current Unicode versions |
DevOps & Webmaster Guide: Deploying IDNs into Production
When provisioning server certificates, web server host headers, and reverse proxies for internationalized domains, standard tooling often mandates ASCII input. Follow these engineering guidelines:
Web Server VirtualHost Configuration
- • Nginx server_name: Always define the ACE punycode in
server_name:server_name xn--mnchen-3ya.de xn--qxaa.xn--qxam xn--hxajb6cu4a.gr; - • Apache ServerAlias: Specify both the Punycode host and the raw IDN to ensure incoming HTTP/1.1
Hostheaders match reliably across varying user agents. - • Canonical Rel Tags: In HTML headers, link canonical URLs using either format consistently, though Punycode guarantees zero character encoding mismatches across search crawlers.
SSL Certificates & Email (EAI)
- • X.509 TLS Certificates: When generating CSRs (Certificate Signing Requests) or invoking Certbot / Let's Encrypt, request the SAN (Subject Alternative Name) using the Punycode hostname:
d:xn--mnchen-3ya.de. - • Email Address Internationalization (EAI): While SMTPUTF8 (RFC 6530) enables native UTF-8 mailboxes, many legacy mail gateways reject non-ASCII envelope addresses. Always provide an ASCII alias.
- • SEO Redirects: Pair internationalized brand domains with 301 redirects pointing to your primary canonical domain, ensuring full link equity consolidation.
Frequently Asked Questions (FAQ)
What is an Internationalized Domain Name (IDN) and why is Punycode required?
The legacy Domain Name System (DNS) historically only permitted a subset of 7-bit ASCII characters: letters A through Z, digits 0 through 9, and hyphens (the LDH rule). Internationalized Domain Names (IDNs) allow native language characters like umlauts, Greek, Cyrillic, Hebrew, Arabic, and CJK characters. Punycode (defined in RFC 3492 and RFC 5891) translates non-ASCII Unicode strings into an ASCII-Compatible Encoding (ACE) format starting with the prefix ‘xn--’ so that standard DNS root servers, authoritative name servers, and resolvers can resolve them without modifying core infrastructure.
Does this converter support Greek script and the .ελ top-level domain?
Yes. It fully supports the Greek alphabet (Α-Ω, α-ω), diacritics/tonos (ά, έ, ή, ί, ό, ύ, ώ), diaeresis (ϊ, ϋ), and the non-Latin Greek country-code top-level domain (.ελ, which resolves to Punycode ‘xn--qxam’). Under IDNA2008 standards, Greek final sigma (ς) is preserved accurately as a distinct code point without collapsing into medial sigma (σ).
What does the “xn--” prefix signify in domain names?
The ‘xn--’ prefix is known as the ACE (ASCII-Compatible Encoding) prefix designated by IANA. It indicates to DNS resolvers, web browsers, and mail servers that the remaining ASCII characters represent an algorithmic encoding of Unicode characters rather than an ordinary Latin host name.
How does IDN homograph phishing work and how does Punycode prevent it?
IDN homograph attacks occur when malicious actors register domain names that visually imitate trusted websites using look-alike characters from different alphabets (e.g., replacing Latin ‘o’ (U+006F) with Greek omicron ‘ο’ (U+03BF) or Cyrillic ‘о’ (U+043E)). Modern browsers mitigate this risk by inspecting domain labels and automatically falling back to displaying the raw Punycode string (e.g., ‘xn--...’) in the address bar if an IDN mixes character scripts in an untrusted or deceptive manner.
Does this tool preserve full URL protocols, ports, and query paths?
Yes. The converter isolates the authority (domain hostname or IP) from protocol schemes (http://, https://), credentials, ports (:8080), URL paths, and query parameters. Only the domain host labels are encoded to or decoded from Punycode, leaving paths and parameters structurally intact.
Can I convert bulk domains simultaneously?
Yes. You can paste lists with hundreds of domain names or full URLs separated by line breaks into the input workspace. Each line is analyzed and transformed independently in real time.
What is the difference between IDNA2003 and IDNA2008 standards?
IDNA2003 used algorithmic mapping based on Unicode 3.2, which caused discrepancies with characters such as the German sharp S (ß) mapping to ‘ss’, or Greek final sigma (ς) collapsing to medial sigma (σ). IDNA2008 (RFC 5890-5894) replaced algorithmic case folding with strict code-point validity categorization, allowing characters like ‘ß’ and ‘ς’ to have independent Punycode representations without unexpected substitutions.
Related & Complementary Utilities
Explore more privacy-first client-side web tools.
Meta Tag Generator & Social Preview Inspector
Generate SEO-optimized HTML meta tags, Open Graph properties, and Twitter Cards with live previews for Google, Facebook, & X. 100% client-side & secure.
WHOIS Domain Age Checker & Expiration Auditor
Query live WHOIS registries to inspect domain creation dates, total active age, registrar information, expiration milestones, and trust metrics.
IP Location Lookup & GeoIP Visualizer
Inspect IPv4/IPv6 locations, ASN telemetry, ISP network data, and interactive location maps.