Punycode and Homograph Attacks: When a URL Looks Real But Isn't

Published: 19 April 2026 • 8 min read • By ScanTotal Security Team

Last reviewed: 4 May 2026 by Kumari Rajapaksha, Founder, ScanTotal

Here's a question that sounds like a trick: are these two domain names the same?

They look identical in most fonts. They aren't. The second one is built from Cyrillic characters that happen to look exactly like their Latin counterparts. Register it, put a login page on it, and send someone a link, if they rely on their eyes alone, they have no way of telling it apart from the real thing.

This is called a homograph attack, and it's one of the older and more elegant tricks in the phishing playbook. It's also the reason your browser's address bar sometimes shows you a domain starting with xn-- instead of the pretty version, that's punycode, the internet's defence mechanism against exactly this problem.

Why lookalike domains exist in the first place

The Domain Name System was originally ASCII-only. You could have apple.com or amazon.co.uk, but not café.fr or 北京.中国. That was fine in the 1980s and increasingly absurd as the internet became global. People who write in Arabic, Thai, Chinese, Cyrillic, Hindi, or any of the other ~150 scripts Unicode supports wanted domain names in their own language.

The solution was Internationalised Domain Names (IDNs), introduced in 2003. A domain can now contain any Unicode character. To keep the underlying DNS infrastructure unchanged, IDNs are transported as ASCII using an encoding called punycode, and displayed in the user's native script.

The trade-off is obvious in hindsight: if any script can appear in a domain name, you can write apple.com where every letter is actually Cyrillic, U+0430 а, U+0440 р, U+0440 р, U+04CF ӏ, U+0435 е, and it reads identically to the real thing.

How punycode is supposed to protect you

Punycode converts Unicode characters into an ASCII-only form that always starts with xn--. The Cyrillic "apple.com" above becomes:

That second form is ugly by design. Nobody registers a legitimate business under a domain that looks like gibberish, and nobody types it by hand. If your browser shows you xn-- in the URL bar, it's telling you the real domain name is not what the pretty version suggests.

Modern browsers decide which form to show using a set of rules standardised by Unicode and implemented slightly differently across vendors. The general principle: if the domain mixes scripts that shouldn't be mixed, or uses characters that don't belong in the top-level domain, show punycode. If the entire domain is in a single coherent script that matches the TLD's language expectations (a .ru site entirely in Cyrillic, for example), show the pretty form.

Where browser defences work, and where they don't

For straightforward "all-Cyrillic pretending to be all-Latin" attacks on common TLDs, Chrome, Firefox, Safari, and Edge all display punycode. That's a huge win. An attacker registering xn--pple-43d.com and hoping it displays as аpple.com will find their Chrome users seeing xn--pple-43d.com in the address bar.

The defences have gaps, though. Some are technical, some are human.

The address bar isn't the only place URLs show up

A link inside an email, a message, a PDF, a chat application, a social media post, a browser notification preview, or a QR code decoder, these UIs each have their own display rules. Many of them render Unicode faithfully without any script-mixing check. So a link displayed as apple.com in your mail client might actually be xn--80ak6aa92e.com, and you'd only see the punycode after clicking through.

Certificates sometimes disagree with browsers

A certificate authority can happily issue a TLS certificate for an IDN domain. The green padlock reassures users that "the site is who it says it is", except when "who it says it is" includes lookalike Unicode. The padlock is honest; it just can't tell whether a human would read the domain correctly.

Mixed-script attacks inside a single subdomain

Some newer attacks don't bother disguising the whole domain, they attack one subdomain. A URL like login.раypal.com has a Latin "l", "o", "g", "i", "n" subdomain pointing at a Cyrillic "paypal" second-level domain. Some renderers handle this cleanly; others display the whole thing as plain-looking Latin-ish text.

Click-through habits

Even when a browser shows punycode, users who've trained themselves to ignore URL-bar details miss the warning. Phishing is effective precisely because the human-visible cues (branding, layout, tone) say "legitimate" while the machine-visible cues (domain, certificate chain, punycode) say "something is wrong."

Real examples

The most widely cited homograph proof-of-concept was published in 2017 by researcher Xudong Zheng, who registered an all-Cyrillic version of apple.com and hosted a convincing-looking page on it. Chrome and Firefox displayed the pretty form at the time; both vendors patched their defences within weeks. Since then, the research community has documented hundreds of similar registrations, apple, google, microsoft, paypal, facebook, amazon, and local bank names, sitting dormant in registrars, presumably waiting for the right campaign.

Not every homograph is malicious. Some are registered defensively by the real brand to prevent abuse. Some are registered by researchers for papers. Some are registered by domain squatters hoping to sell them. But a percentage end up on phishing kits aimed at banks, email providers, and cryptocurrency exchanges, and those are the ones worth knowing how to detect.

Three checks you can do

1. Copy the domain into a plain text editor

Open Notepad, TextEdit, or any code editor with a monospace font. Paste the domain. Monospace fonts expose inconsistencies that proportional fonts hide, the Cyrillic "а" is subtly different from the Latin "a" when every glyph has the same width. It's not a perfect test (some lookalikes are nearly pixel-identical), but it catches the obvious cases in seconds.

2. Scan the URL

Paste the URL into our URL Scanner. The scanner resolves the domain to its punycode form behind the scenes and checks it against reputation databases, heuristic rules, and live probes. If the domain decodes to an xn-- form, that's called out explicitly in the result. If it's a known phishing impersonation, reputation data flags it directly.

3. Inspect the certificate

Click the padlock in your browser and read the certificate. Legitimate brands usually hold certificates that list their verified organisation name (particularly on banking and payment sites). A random-looking certificate with no organisation validation on a domain claiming to be a major brand is a strong red flag.

What browsers are doing about it

Browser vendors have been actively tightening homograph defences for years. Chrome's IDN display policy is public and detailed, covering dozens of edge cases. Firefox maintains its own display algorithm. Safari, Edge, and Opera have equivalent logic. Credit where it's due, a lot of phishing that would have worked in 2017 is blocked by default in 2026 browsers.

The remaining work is outside the browser. Email clients, messaging apps, and custom "link preview" implementations don't always apply the same rules, and that's where the next wave of homograph campaigns tend to land. Keeping everything patched, sending suspicious links through a URL scanner before you tap them, and training yourself to glance at the address bar after you arrive, those habits close most of the gap.

The takeaway

Homograph attacks exist because the internet is multilingual and human eyes are pattern-matchers. Punycode is the quiet protocol-level fix; browser display rules are the user-facing layer on top of it. Between them, most attacks are surfaced as weird-looking xn-- prefixes. The ones that slip through tend to exploit environments other than the browser URL bar, email, messaging, QR codes, notifications.

If a link in any of those places leads somewhere critical (banking, email, identity), the cheapest defence is to copy-paste the URL into a scanner before you tap it. It takes five seconds and catches the attacks that a glance at the link text might miss.