Punycode Converter
Note: Several Cyrillic letters are visually identical to Latin ones, so a domain mixing scripts can look exactly like a familiar name and resolve somewhere else. Any mixed-script label below is flagged, with the characters responsible named.
That gap is where the practical problems live. TLS certificates, DNS records, mail server configuration, WHOIS lookups, allowlists in a firewall, and analytics reports all deal in the encoded name. If you have registered an internationalised domain and something is silently failing, the encoded form is usually the value the configuration actually wants.
Encoding is per label. Each part between the dots is converted separately, and only the parts that contain non-ASCII characters get the prefix — which is why münchen.example.com becomes xn--mnchen-3ya.example.com rather than encoding the whole thing.
The homograph check is the other half of the tool. Several Cyrillic letters are visually identical to Latin ones, so аpple.com written with a Cyrillic а renders exactly like the real thing while resolving somewhere else entirely. Browsers defend against this by showing the raw Punycode when a domain mixes scripts, so the check here flags mixed-script labels and names the characters responsible — useful both when auditing a suspicious link and when you have unintentionally pasted a Cyrillic character into your own domain.
Frequently Asked Questions
What does the xn-- prefix mean?
It marks a label as Punycode-encoded, and it is how software knows to decode it back to Unicode for display. A label without the prefix is read as literal ASCII, which is why you cannot simply write the encoded characters without it.
Why does my browser show xn--… instead of the readable name?
Because the label mixes scripts, and displaying it would let a Cyrillic character impersonate a Latin one. Browsers fall back to the raw Punycode as a deliberate anti-spoofing measure. If it happens to your own domain, one of the characters is not from the script you think it is.
Where do I need the encoded form?
TLS certificates, DNS zone files, mail server configuration, WHOIS queries, firewall allowlists and most analytics tools. Anywhere the value is stored or compared rather than displayed, it is the ASCII form that is actually in use.
Does Punycode apply to the path or the query string?
No, only to domain labels. Non-ASCII characters elsewhere in a URL are percent-encoded UTF-8 instead, which is a completely different mechanism. A URL can quite legitimately contain both.
Is an internationalised domain bad for SEO?
Not in itself — search engines handle them fine and display the readable form. The practical costs are elsewhere: people mistype them, some older software mangles them, and links shared as raw Punycode look untrustworthy to anyone who does not recognise the prefix.
