A homograph attack registers a domain built from characters that look identical to the ones in a real domain but are not - a Cyrillic "a" standing in for a Latin "a", for instance - so the address a person reads and the address a browser resolves are two different things. The trick works because the domain name system only understands ASCII, so every non-ASCII domain gets translated into an ASCII form called punycode, flagged with an xn-- prefix, before it ever touches DNS. Browsers decode that back into the readable version for display, and that decode step is exactly where the deception lives.
Modern browsers now catch the obvious cases and fall back to showing raw punycode when a label mixes scripts in a suspicious way, closing off most of the easy attacks that worked a decade ago. But that protection doesn't leave the browser address bar.
I look at brand-spoofing cases for a living, and the good fakes still catch my eye for a half-second before the giveaway registers. This post covers how a homograph attack works, where the browser's defense stops, and what to do about it - whether you are about to click, or you own the domain being spoofed. For the wider question of whether short links themselves are trustworthy, are URL shorteners safe covers that ground; this one is about the domain sitting underneath the link.
What Punycode Is and Why It Exists
DNS was built for ASCII, full stop. It has no native way to store the accented letters, Cyrillic, Arabic, or Chinese characters that make up most of the world's writing systems, which was a real problem the moment domain registration opened up outside English-speaking markets.
Punycode is the fix: a reversible encoding, standardized as RFC 3492, that converts a Unicode label into ASCII letters, digits, and hyphens DNS can carry without any change to the wire protocol. A German bakery registering a domain with an umlaut, or a Ukrainian retailer registering one in Cyrillic, gets a working internationalized domain name that resolves exactly like any other, because underneath it is just another ASCII label. The encoded form always starts with xn--, signaling "this is punycode, decode before you show it to a human."
None of that is a vulnerability by itself - internationalized domain names are a genuine, necessary feature, not a workaround anyone should disable. The trouble starts one layer up, at the moment a browser decides how to display that decoded name back to you.
How a Homograph Attack Works
A homograph attack exploits the gap between what a domain contains and what it looks like once rendered. Two variants show up in the wild, and they are not equally common.
The whole-script version registers an entire domain in a non-Latin script whose letterforms happen to resemble the target brand. It is conspicuous to build and easier for defenders to catch, since the whole label is foreign.
The mixed-script version is the one that actually gets used, because it needs only a single substitution. Take a domain like novacloud.com. Swap the Latin "o" for the visually identical Cyrillic "о" (U+043E) and you get nоvacloud.com - same shape, same length, different code point, and a domain that encodes to xn--nvacloud-nbh.com. Everything else in the label stays untouched, so the eye has almost nothing to flag. Security researchers call this kind of lookalike pair a "confusable," and a handful of them cover most of the Latin alphabet.
Once the domain is registered, the rest of the attack is ordinary phishing: a login page copied pixel for pixel, an urgent message pointing at the spoofed link, and a target who has no reason to doubt an address that looks exactly right.
What Browsers Do About It Today
Browser vendors closed most of the easy version of this attack years ago with a rule about which scripts are allowed to mix in one label. Chrome's policy, documented in its IDN handling guide, checks whether every character in a label plausibly belongs to one script, or to a small set of script combinations that legitimately appear together, like Japanese kanji with hiragana. Mix scripts outside that allowed set and the browser shows the raw xn-- form instead of decoding it - the attack's best asset, a domain that looks completely normal, turns back into an obviously encoded string. Firefox runs a comparable check, described in Mozilla's IDN display algorithm, and Safari applies its own version.
It isn't complete protection. A mixed-script label built only from characters inside one allowed combination can still slip through as a readable, deceptive name, and the rule is enforced browser by browser, with no shared authority deciding what counts as safe.
Where That Protection Stops
The script-mixing check lives in the browser's address bar rendering code. It does not travel with the URL anywhere else, and that gap is where a spoofed domain still does real damage.
Email clients are the biggest exposure: a message can display any anchor text over a link regardless of the destination, and most mail apps run no confusable check at all. Chat apps unfurl a shared link into a preview card built from page metadata, not a punycode-aware renderer. QR codes remove the text step entirely, a gap we cover in are QR codes safe, and printed material has no software layer between the eye and the deception.
| Channel | Shows real destination before you act | Typical exposure |
|---|---|---|
| Modern desktop browser | Usually, via script-mixing rules | Low for common browsers, kept current |
| Email client | Rarely - anchor text can say anything | High, especially on mobile mail apps |
| Chat and messaging apps | Rarely - link previews use page metadata | High, link unfurls look identical |
| QR code | No - nothing renders until after the scan | High, decision happens in a split second |
| Printed material | Never - no software is involved at all | Highest, no technical check is possible |
If your team sends links under a domain your customers already recognize, a spoofed lookalike has far less room to imitate you convincingly across all of those channels at once. See how a custom branded domain works on Elido if you are still sending links from a shared or generic domain.
Why a Branded Domain Is Your Best Defense
A homograph attack works by exploiting familiarity - it needs a recognizable brand to counterfeit. That sounds like an argument against building a recognizable domain of your own, and it's the opposite. A distinctive branded short link that your audience already associates with you is something they can compare a suspicious message against; a generic or borrowed shortener domain gives an attacker a template customers cannot distinguish from the real provider anyway, because neither one looks like "you."
Setting up a custom domain for short links means every link you send carries a name recipients recognize, which raises the bar for anyone trying to counterfeit it. Worth separating from link cloaking and URL masking, a deliberate, disclosed choice to route links through your own domain. A homograph attack is the opposite move - concealing the attacker's identity while imitating yours - and the defense is transparency about which domain is actually yours.
The Registrar Controls That Actually Matter
Two controls do most of the real work once you own a domain worth protecting, and they operate at different levels of the stack.
Registrar lock is the everyday one - a status flag, often shown as clientTransferProhibited, that blocks routine automated transfer requests inside your registrar's own dashboard. Every domain you actively use should have it on; it costs nothing. Registry lock sits a level higher, engaging the registry operator directly so any change, transfer, or deletion requires manual, out-of-band verification - a phone call or a secure passphrase - before it takes effect. That friction belongs on the one or two domains where an unauthorized change would be genuinely expensive, which for most companies means the primary brand domain at minimum.
Neither lock stops someone from registering a lookalike domain next to yours. That needs active monitoring: watching new domain registrations and public certificate-transparency logs for names visually close to your brand, so you can report it to the registrar or alert customers before a campaign using it reaches anyone.
What to put in a brand-protection policy
If you own a domain worth spoofing, the security section of your brand-protection policy should be specific enough that someone new to the team could execute it without asking you first.
- Registrar transfer lock on every domain the company owns, with registry lock added on the primary brand domain and anything that handles payments or logins.
- A recurring cadence for scanning new domain registrations and certificate-transparency logs for names visually close to your brand, not a one-time check.
- Defensive registration of the highest-risk lookalike labels and confusable top-level domains you can justify, prioritized by how closely they match your primary domain.
- A named owner and an escalation path for reporting a discovered lookalike domain to its registrar, plus internal guidance so support staff recognize the pattern when a customer reports one. The security checklist for choosing a link provider covers the adjacent vendor controls.
A Verification Recipe Anyone Can Follow
You don't need to understand punycode to check a link safely. Four steps, done in order, catch nearly everything a homograph attack relies on.
- Expand the link first, rather than clicking it directly. How to see where a short URL goes walks through the tools for this, and Elido's own link checker does the same thing without asking you to trust the destination first.
- Read the registrable domain - the part immediately before the top-level domain - rather than anything that appears before it. That is the part an attacker has to control entirely.
- Check for an xn-- prefix, either in the raw expanded URL or in your browser's address bar. If you see one where you expected a plain brand name, stop and treat it as a lookalike until proven otherwise.
- Confirm the certificate name on the destination site. A certificate reflects what was actually issued to a domain owner, which is a harder thing to fake convincingly than a rendered label.
None of these steps take more than a few seconds once they're habits, and you can teach all four to a non-technical colleague in the time it takes to read this section once.
A homograph attack is a display problem wearing a security costume. Punycode is doing exactly what it was designed to do; the deception happens in the gap between what a domain is and what a piece of software shows you instead. Browsers have closed most of that gap for the address bar. Everywhere else the gap is still open, which is why expanding a link and reading the registrable domain remains the habit that works regardless of which channel put the link in front of you.
Related on the Blog
Частые вопросы
What is an IDN homograph attack?
An IDN homograph attack registers a domain using characters from a different script that look identical or nearly identical to the ones in a real domain, so a reader cannot tell the two apart by sight. The classic case swaps a single Latin letter for a Cyrillic or Greek lookalike, for example the Cyrillic a for the Latin a, while everything else in the domain stays unchanged. Because the substitute character has a different underlying code point, the two domains are technically distinct and can be registered and controlled by different owners. The attack succeeds purely on appearance, which is why it targets recognizable, trusted brand names rather than obscure ones.
What is punycode and why does it exist?
Punycode is the encoding that turns non-ASCII domain labels into an ASCII string the domain name system can store and resolve, defined in RFC 3492. It exists because DNS only understands a limited ASCII character set, so a domain written in Cyrillic, Arabic, Chinese, or with accented Latin letters has to be translated into that form before it can be looked up. The encoded label always starts with the xn-- prefix, which tells resolvers and browsers that what follows is a punycode-encoded string rather than a plain ASCII name. Browsers then decode it back to the original script for display, which is a legitimate and necessary feature, not the vulnerability by itself.
What does the xn-- prefix mean in a URL?
The xn-- prefix marks a domain label as ASCII Compatible Encoding, produced by punycode, signaling that the readable name was translated from non-ASCII characters. Everything after the prefix is the encoded form of the original label - xn--nvacloud-nbh.com, for instance, decodes to a domain that looks like novacloud.com with one letter swapped for a lookalike. Seeing the xn-- form where you expected a plain brand name is exactly the tell browsers use to warn you, because it means the label mixed scripts in a way the browser did not consider safe to render as the pretty version. A domain with no non-ASCII characters never produces an xn-- form, so seeing one is always worth a second look.
Do browsers protect against homograph attacks?
Modern browsers apply script-mixing rules that catch most homograph attempts and fall back to showing the raw punycode form instead of the deceptive one. Chrome and Firefox both check whether a domain label's characters plausibly belong to a single script or a small set of scripts commonly used together, and if not, they display the xn-- version rather than decode it into something that could pass for a familiar name. That closes off the easiest whole-script attacks from being shown as convincing impostors, though attackers can still find characters within the allowed sets that are visually confusable with Latin letters. The protection is also strictly limited to the browser address bar - nothing else in the stack inherits it automatically.
How can I tell if a link is a lookalike domain before I click it?
Expand the link first so you see the full destination rather than a short or truncated version, then read the registrable domain rather than anything that comes before it. If the address bar or the expander shows an xn-- prefix where you expected a plain brand name, treat that as a lookalike domain until proven otherwise. Confirming the certificate name on the destination site is a useful final check, since a certificate reflects what was actually issued rather than what merely gets displayed. None of this needs special software - just the habit of doing it before you enter a password or a card number.
What is registry lock and does my domain need it?
Registry lock is a control set at the domain registry level that blocks any change, transfer, or deletion of a domain until it is manually verified out of band, typically by phone or a secure passphrase, which stops even a compromised registrar account from moving the domain. It is a stronger guarantee than the more common registrar lock, which only prevents routine automated transfers inside your own registrar dashboard. Registry lock is worth its modest annual cost for any domain whose downtime or hijacking would be expensive, which for most companies means the primary brand domain at minimum. It will not stop someone from registering a similar-looking domain next to yours - that is a separate problem solved by monitoring, not locking.
Попробуйте Elido
Вставьте URL - получите короткую ссылку
Без регистрации. Ссылка живёт 30 дней. Зарегистрируйтесь, чтобы оставить её навсегда.
Бесплатно, без регистрации · 2 в день