Spotting IDN Homograph (Punycode) Phishing Domains: What xn-- Tells You and What It Doesn't

аpple.com and apple.com look identical in most fonts. They aren't the same domain: the first letter of the first one is Cyrillic а (U+0430). DNS only speaks ASCII, so that label is really stored as xn--pple-43d.com, a name anyone can register.

The reliable check is simple: encode what you see into Punycode. If a name that should be plain English comes back with an xn-- label, it contains non-Latin letters and it isn't the real site. Below is what I found running real conversions on November 2, 2026 (PHP idn_to_ascii, ICU 71.1, plus Chrome 156 for browser behavior).

Encoded examples

A handy tell: the readable part before the last hyphen keeps only the ASCII letters of the label. In xn--l-7sba6dbr, only the l of "paypal" survived.

Encode, don't decode

If someone hands you xn--80ak6aa92e.com, decoding it gives you аррӏе.com, which is exactly the illusion the attacker wants. Decoding shows what they want you to see; encoding what you see shows what it really is.

Where browsers protect you, and where they don't

• Chromium (Chrome, Edge, Brave) shows a label as xn-- when it mixes Latin/Cyrillic/Greek, and also when an all-Cyrillic label looks Latin on a non-Cyrillic TLD.
• Firefox blocks mixed scripts but, by its published IDN algorithm, allows whole-script lookalikes. Set network.IDN_show_punycode to true in about:config to always see the encoded form.
• Everywhere else (email bodies, SMS, chat, PDFs, bios) the link is just text in a font. Nothing checks it, and that's where these links actually arrive.

The padlock proves nothing here: the certificate is simply issued for the xn-- name.

Pitfalls when you test a link

• Strip the scheme. Feeding https://аpple.com/login to a label-based encoder produces garbage like xn--https://pple-49j.com/login. Keep just the host (a path is fine).
• Watch for @. In https://accounts.google.com@аpple.com/, everything before @ is userinfo. The host is аpple.com.
• Read right to left. apple.com.evil.example belongs to whoever owns evil.example, Punycode or not.
• One domain per run. Line breaks can get treated as part of a label.
• Empty output is not "clean". Invalid Punycode like xn--zz.com can return nothing; an invalid label in a link is itself suspicious.
• IDNA2003 vs IDNA2008. Transitional mapping turns faß.de into fass.de, while Chrome resolves xn--fa-hia.de, a different domain. Same story for Greek final ς and ZWJ/ZWNJ. Rarely matters for phishing checks, but matters a lot if you're writing DNS records.
• ASCII lookalikes (rn for m, 1 for l, paypal-secure-login.com) pass any IDN test. Check domain age with WHOIS instead.

xn-- isn't automatically bad

españa.com is xn--espaa-rta.com, пример.рф is xn--e1afmkfd.xn--p1ai, 💩.la is xn--ls8h.la. The red flag is narrower: an xn-- label in a name that should only contain English letters.

I wrote the full guide, with the browser IDN rules and what to do when you find a fake, on the My Botsy blog: How to Spot a Punycode Phishing Domain. If you want to try the examples above without writing code, there's a free Punycode converter there too (I help build it; the pitfalls above include its own current limitations).