How to Decode a Punycode Domain Name

A log line contains a request to xn--80ak6aa92e.com and you’d quite like to know what that actually says before deciding whether it matters. Or a certificate lists a domain in that form, or an email header does, and the readable version is somewhere behind an encoding you can’t do in your head.

Punycode is one of those pieces of internet plumbing that’s invisible until suddenly it’s in front of you, and then there’s no obvious way to read it.

What punycode actually is

The domain name system was designed around a restricted character set: letters, digits, and hyphens. That’s a problem if your language isn’t written in that alphabet, which is most of them.

Punycode is the workaround. It encodes a Unicode string into that restricted set, producing a label prefixed with xn--. So a domain written in Cyrillic, Arabic, Chinese, or with accented Latin characters is stored and transmitted as ASCII, and browsers decode it back for display.

The encoding is deterministic and reversible. xn-- followed by the encoded portion always maps back to exactly one Unicode string — there’s no ambiguity, which is why decoding is a mechanical operation rather than a guess.

Each label is encoded separately. In xn--e1afmkfd.xn--p1ai, both the second-level and top-level labels are encoded independently, which is why you sometimes see two xn-- segments in one name.

Why this matters beyond curiosity

The interesting case is that many Unicode characters look like Latin ones. A Cyrillic “а” is visually near-identical to a Latin “a” in most fonts, and a domain using one in place of the other renders as something that looks entirely familiar.

This is the basis of homograph attacks, and it’s why browsers have rules about when they display the decoded Unicode form and when they show the raw punycode instead. If a label mixes scripts in suspicious ways, many browsers deliberately show the xn-- form as a warning signal.

So decoding punycode is genuinely useful for two different reasons: understanding a legitimate internationalised domain, and checking whether an unfamiliar one is impersonating something.

Common mistakes to avoid

• Assuming xn-- means malicious. The vast majority of internationalised domains are entirely legitimate. It’s an encoding, not a warning.
• Decoding only the second-level label. Check every label; a name can encode more than one.
• Trusting the decoded form visually. If the decode produces something that looks exactly like a familiar Latin brand name, that’s the case to be suspicious about, not reassured by.
• Forgetting the case-insensitivity. Domain labels are case-insensitive, so XN-- and xn-- are the same thing.
• Pasting suspicious domains into random online tools. If you’re investigating something, a tool that runs locally avoids telling a third party what you’re looking into.

What a good decoder does

Handles each label independently

A full domain with multiple encoded labels should decode entirely, not just the first part.

Shows the script of the result

Knowing the decoded characters are Cyrillic rather than Latin is often the whole answer, and it isn’t visible from the characters themselves.

Runs locally

Domains you’re investigating during an incident are sensitive. A browser-based decoder means the lookup doesn’t leave a record anywhere else.

How to do it with Punycode to Unicode

Online Tool Store’s Punycode to Unicode decodes punycode domains into readable Unicode labels in your browser, with nothing sent to any server.

1. Paste the full domain, including every label — not just the part after the xn--.
2. Read the decoded result, and note which script the characters belong to.
3. If the decode produces something resembling a well-known brand in Latin characters, treat that as a red flag rather than a confirmation.
4. Check whether any single label mixes scripts, which is the classic homograph signal.
5. For an incident, record both the encoded and decoded forms in your notes — the encoded form is what your logs and tooling will match on.

The Unicode to Punycode tool handles the reverse, and the IDN Punycode Phishing Detector and Phishing URL Analyzer cover the security side.

Frequently asked questions

Is a domain starting with xn-- dangerous?

Not inherently. It simply means the domain contains non-ASCII characters, which is normal for the large share of the world that doesn’t write in the Latin alphabet. The risk is specifically with domains designed to look like existing Latin-script ones.

Why does my browser sometimes show xn-- instead of the readable name?

Browsers apply heuristics about script mixing and character confusability. When a name looks like it could be impersonating another, many browsers deliberately show the raw punycode so the user sees something visibly unusual.

Can I decode punycode without a tool?

The algorithm is well-specified and implemented in most programming languages’ standard libraries, so it’s a one-liner in code. Doing it mentally isn’t practical — the encoding involves a variable-length integer scheme that isn’t readable by inspection.

Final thought

Decode every label, check the script, and be more suspicious when the result looks familiar than when it looks foreign. That inversion is the whole security insight of internationalised domains.

Try the free Punycode to Unicode tool