IDN Domains Explained: Why Your URL Shows as xn--...

A customer messages support convinced their domain got hacked — the address bar now shows something like xn--e1aybc.xn--p1ai instead of the name they registered. Nothing was hacked. That's Punycode, and once you understand why it shows up, it stops being scary and starts being a five-minute fix.

Symptom: Your Domain Turns Into a String of Random Letters

You register a domain using non-English characters — maybe a Hindi brand name in Devanagari script, or a domain someone sends you that has an accented letter in it — and somewhere along the way it turns into an ugly ASCII string starting with xn--. It shows up in:

• The browser address bar, instead of the script you typed
• WHOIS lookups and registrar dashboards
• Email headers, when someone emails you from that domain
• cPanel's Zone Editor, when you go to add a DNS record

None of this is corruption or a hijack. It's the domain doing exactly what it's designed to do.

Cause: DNS Only Speaks ASCII, So Browsers Translate

The domain name system was built in the 1980s around a strict character set — letters A-Z, digits 0-9, and hyphens. That's it. No accents, no Devanagari, no Cyrillic, no emoji. When Internationalized Domain Names (IDNs) were added in the early 2000s, nobody could change how DNS servers talk to each other, so instead they added a translation layer called Punycode (RFC 3492).

Punycode takes a Unicode label like दुकान and re-encodes it into an ASCII-only string prefixed with xn--, which is safe to store in DNS zone files, pass through mail servers, and put in SSL certificates. This ASCII form is called the domain's ACE (ASCII-Compatible Encoding), and it's the domain's real, canonical name as far as every server on the internet is concerned. The pretty Unicode version is just a display layer on top.

If you're registering an Indian-language domain, this matters more than most people expect. India has its own IDN ccTLDs run under the .bharat program — .भारत (Devanagari), plus Tamil, Bengali, Gujarati, Punjabi, Urdu, and Telugu script variants. Every one of them resolves through a punycode ACE string behind the scenes.

Why Chrome Sometimes Shows Punycode Even for "Normal" Scripts

Modern browsers apply an extra safety check before they'll render the Unicode form. If a domain label mixes characters from multiple scripts, or uses characters that look identical to Latin letters (Cyrillic "а" instead of Latin "a", for example), the browser deliberately falls back to showing the raw xn-- string. This is intentional — it's an anti-phishing measure, because а mixed-script lookalike domain is a classic way to impersonate a bank or login page. If your own legitimate domain is entirely in one consistent script, browsers will usually render it correctly; if it still shows as punycode, the registrar's IDN table for that TLD may not be on the browser's trusted allowlist yet.

Fix: Getting Everything to Agree on the Same Form

Most support tickets we get about IDN domains aren't actually about the punycode string itself — they're about something downstream breaking because two systems disagree on which form (Unicode or ACE) to use.

1. DNS Zone Records

Always work with the ACE (xn--...) form in cPanel's Zone Editor or WHM's DNS functions. If you paste the Unicode name into a text field that doesn't auto-convert, the record silently fails to resolve. Convert it first with any punycode encoder, then add the A, MX, or TXT record using the xn-- version:

xn--d1b6a8b.xn--h2brj9c.  IN  A     203.0.113.10
xn--d1b6a8b.xn--h2brj9c.  IN  MX 10 mail.yourhost.com.

2. SSL Certificates

AutoSSL and Let's Encrypt both issue certificates against the ACE form — that's what shows up in the certificate's Common Name and SAN fields, not the Unicode script. This is normal and won't trigger a mismatch warning as long as the domain in cPanel and the domain the visitor's browser requests both resolve to the same punycode string. If you're getting an SSL name-mismatch error on an IDN domain, check that the domain was added to cPanel using the exact ACE form under Domains, not a manually typed Unicode version that has a subtly different encoding.

3. WordPress Site URL

If WordPress is installed on an IDN domain, siteurl and home in wp_options must be stored in the ACE form. A database import from a different environment sometimes writes the Unicode form instead, which breaks the site to a "not found" or a redirect loop. Fix it with WP-CLI:

wp option update siteurl 'https://xn--d1b6a8b.xn--h2brj9c'
wp option update home 'https://xn--d1b6a8b.xn--h2brj9c'
wp search-replace 'दुकान.भारत' 'xn--d1b6a8b.xn--h2brj9c' --all-tables

If you don't have SSH access, the same two options can be edited from phpMyAdmin → wp_options table → rows where option_name is siteurl or home.

4. Email Deliverability

SPF and DKIM records for an IDN domain must reference the ACE form too. A common mistake is publishing an SPF TXT record under the Unicode label — Exim and other mail servers look up the ACE-encoded name during a DNS check, so a record sitting under the wrong label is invisible to them and mail starts failing SPF alignment.

Prevention: What to Check Before You Register or Migrate

• Before buying an IDN domain, punycode-encode it yourself and search that string — some registrars display availability by Unicode label, which can mask that the ACE string is already taken or reserved.
• When adding the domain in cPanel, copy the ACE form directly from your registrar's dashboard rather than retyping the Unicode name — a single wrong character produces a different, unrelated punycode string.
• Bookmark a punycode converter and keep the ACE string handy in your notes for the domain — you'll need it every time you touch DNS, SSL, or wp-config.
• If brand protection matters, register the obvious Latin-script confusables of your name too. Homograph domains are cheap to register and are a real phishing vector for anyone recognizable in their local script.

When to Just Ask Support

If your domain is resolving fine and only "looks wrong" in the address bar, that's cosmetic and not worth chasing. If email is bouncing, SSL won't issue, or the WordPress site is throwing redirect errors right after adding an IDN domain, that's almost always a form-mismatch between Unicode and ACE somewhere in the chain — and it's usually fixed in one support ticket once we see the exact punycode string cPanel has on file.