What a lookalike domain actually is

A lookalike domain is an address that resembles another, more familiar domain closely enough to pass a quick glance. Some lookalike domains are deliberately registered for impersonation — substituting visually similar characters within the standard Latin alphabet (a zero for the letter O, “rn” for “m”), using characters from entirely different scripts that render nearly identically to Latin letters at typical reading sizes (a technique called a homograph attack), or rearranging or adding words around a familiar brand name. Visual similarity alone does not prove that intent, though — two domains can resemble each other for unrelated, non-deceptive reasons, including coincidence or shared naming conventions in an industry. Spotting a genuinely deceptive lookalike requires understanding the actual structure of a domain name and weighing it alongside context, not treating visual resemblance by itself as proof of deception.

The structure: hostname, registrable domain, subdomain, top-level domain

A web address’s hostname is the complete block of text between the scheme (https://) and the first following slash. Within that hostname, the registrable domain — sometimes called eTLD+1 — is generally the public suffix plus the one domain label immediately preceding it. It is a parsing concept: a consistent way to identify the relevant site or domain portion of an address for comparison purposes. Public Suffix List entries themselves are a mix of registry-controlled endings (like .com or .co.uk) and privately operated suffixes that some hosting and platform providers have added to the list for their own services. Identifying the registrable domain does not, by itself, identify the real-world person or organization operating the site, and it is not a hard security boundary — it is a useful comparison aid, not a conclusive ownership or security determination on its own. Everything to the left of the registrable domain in the hostname is a subdomain, which the registrant can set to anything at all, including a misleading brand name; a registrant can also delegate a subdomain to a different service provider or third party, so text appearing in the subdomain position is not necessarily operated directly by the registrant either. The top-level domain is the final segment — .com, .net, a country code like .uk, and so on.

Why counting dots does not reliably identify the registrable domain

A simple shortcut — take the final two dot-separated labels as the domain — works for a plain address like accounts.example.com. It fails for addresses ending in a multi-label public suffix, an ending under which many unrelated parties register names, similar to how many unrelated sites share the plain ending .com. Endings like .co.uk and .com.au are exactly this: two-label public suffixes. Applying the two-label rule to login.example.co.uk gives co.uk — not a registrable domain at all, just the shared suffix; the actual registrable domain is three labels, example.co.uk, because the public suffix itself already occupies two. There is no single fixed number of labels that works across every ending, which is why a dot-counting shortcut is unreliable and why browsers and security tools instead consult a maintained reference, the Public Suffix List.

Applying this to a deceptive address

Now apply the same method to an address built to mislead: https://example.com.login-security.test/secure. Reading left to right and stopping at “example.com” gives the wrong answer. Working correctly from the public suffix inward: .test is the top-level domain here (reserved for testing and documentation, used in this guide for exactly that reason), so the registrable domain is login-security.test. The text “example.com” earlier in the address is just a subdomain label, chosen freely by whoever controls login-security.test, and it establishes no ownership or affiliation with the real example.com whatsoever. This is a well-documented deceptive pattern: placing a familiar brand word in a position of the address that has no bearing on actual control.

Character-substitution techniques within standard Latin text

None of these require any special script or encoding — they use entirely ordinary Latin letters, numbers, and hyphens, arranged to be misread quickly rather than to exploit any technical rendering quirk.

Internationalized domain names, Unicode, and Punycode

Domain names can also include characters beyond the basic Latin alphabet, through a system ICANN calls Internationalized Domain Names (IDNs) — letters with diacritical marks required by many European languages, or characters from entirely different scripts such as Arabic, Chinese, or Cyrillic. Because the domain name system’s underlying protocol only handles a restricted character set, ICANN’s documentation explains that the Unicode form a person sees (a “U-label”) is converted into an ASCII-compatible encoding (an “A-label”) before it is stored in the DNS — this encoding is what is commonly called Punycode, visually recognizable by an xn-- prefix. IDNs have legitimate multilingual uses, and IDN usage alone is not evidence of abuse; the relevant risk is narrower and specific — a small number of characters across different scripts can render identically or near-identically to Latin letters at normal reading sizes, which occasionally gets exploited to construct a deceptive address that displays as a trusted name. Treating every non-Latin domain as inherently suspicious would be both inaccurate and unhelpful; the relevant question is not “does this domain use non-Latin characters” but “does this specific domain visually resemble a brand I already trust, in a context where I would not otherwise expect that brand to use this particular address.”

How browsers handle this, and what they do not catch

The WHATWG URL Standard includes security-oriented guidance on URL rendering that specifically flags this risk, noting that characters and character sequences like 1/l/I, m/rn, 0/O, and lookalike characters across scripts can appear confusingly similar, and that invisible formatting characters pose a related concern. How that guidance is actually implemented varies by browser and by version: some browsers convert certain domains that mix scripts in flagged ways into their Punycode form rather than displaying the deceptive rendered version, but this is not a uniform, automatic protection applied identically everywhere — coverage differs by browser and by the specific script combination involved. It also generally does not address same-script substitutions using entirely ordinary Latin characters — “rn” for “m” involves no script mixing at all, so there is nothing for this kind of browser mitigation to flag. In practice, browser-level mitigation reduces one category of risk without covering the full range of lookalike techniques described in this guide, which is why manually reading the registrable domain remains a relevant skill regardless of which browser you use.

A verification workflow that does not rely on memory

1. Do not rely on a general impression of “roughly what the domain looks like.” Search the organization’s name directly and note their actual domain from a source you already trust — an app store listing, a card, or prior correspondence.
2. Identify the registrable domain in the address you are checking, using the public-suffix-aware method above rather than counting dots.
3. Compare the two registrable domains character by character, not as a general shape.
4. If they differ in any way — an inserted word, a substituted character, a different top-level domain — treat the address as unverified regardless of how convincing the surrounding page looks.
5. When genuinely uncertain, navigate to the known-correct domain directly instead of continuing with the address you were given.

A different trick: text placed before an @ symbol

A URL can technically include userinfo — text intended for a username, historically also a password — separated from the actual host by an @ symbol, in the form scheme://userinfo@host/path, as defined in the WHATWG URL Standard. In an address like https://[email protected]/secure, everything before the @ symbol, including the text “example.com,” is userinfo, not the host. The browser connects to login-security.test exactly as if that leading text were not present at all. Because this feature sees little use by ordinary websites, a familiar brand name placed before an @ symbol is a strong deceptive signal on its own — it relies on a reader assuming the text before the @ identifies the destination, when it does not. Some browsers apply additional warnings or restrictions around this specific pattern; coverage is not uniform, so recognizing it on sight remains useful independent of what any particular browser does with it.

Where this pattern commonly appears

Lookalike domains show up across phishing messages (see How to Spot a Phishing Link in an Email or Text Message), fake tech-support warnings (see How to Recognize a Fake Tech-Support Warning), and shortened or QR-encoded links where the real domain is hidden until expanded (see How to Check Where a Shortened Link Goes Without Opening It).

If you already entered information on a lookalike domain

See What to Do After Clicking a Suspicious Link for the ordered recovery steps, which differ depending on whether a password, payment details, or nothing beyond the page itself was entered.

Limitations

Character-by-character review is a useful check, but it is not conclusive on its own. Several factors can complicate it: how a given font or platform renders certain Unicode characters is not always predictable, subdomains and hosting can be delegated in ways that are not visible just from reading the address, a domain can redirect to another domain entirely after the initial check, an unfamiliar domain is not automatically illegitimate just because you do not recognize it, and simple human visual error remains possible even with careful attention. It also requires deliberate effort every time — tiring to sustain consistently, and easy to skip when moving quickly, which is precisely the condition many scam messages are designed to create through urgency. Browser and security tooling catch a portion of known lookalike domains automatically, but new registrations occur constantly and are not always flagged immediately. Treat manual domain-reading as one useful check to apply when something already seems slightly off, in combination with the broader checks in How to Tell Whether a Link Is Safe Before You Click, rather than a conclusive test you can rely on by itself.

Frequently asked questions

If two domains are technically distinct, does that mean they must have different owners?

Two different-looking textual representations are not always distinct normalized domains. Domain matching is case-insensitive, so Example.com and example.com are the same domain, not two different ones. A trailing dot can represent the same fully qualified domain as the version without it. An internationalized domain name and its Punycode (ASCII-compatible) encoding are two different representations of the same underlying domain, not separate domains. Once addresses are correctly parsed and normalized this way, genuinely different registrable-domain values are distinct names — but distinct names still do not imply distinct ownership: the same person or organization can register more than one domain, including deliberately similar-looking ones for their own legitimate purposes, such as protecting a brand from lookalikes. Two distinct domains can also resolve to the same underlying server infrastructure, and one can be set up to redirect visitors to the other. Visual similarity between two domains does not, by itself, establish common ownership in either direction — a similar-looking domain could belong to the same organization, an unrelated party, or someone impersonating the first.

Do browsers protect against every homograph technique?

Coverage varies by browser and script combination, and same-script substitutions using ordinary Latin characters generally fall outside what this specific protection addresses. Manual checking remains a relevant skill for exactly this reason.

Is it unusual for a legitimate business to use a hyphenated or unusual-ending domain?

It happens for genuine reasons — a shortened brand name, a country-specific registration, or a marketing campaign domain. When a hyphenated or unfamiliar-ending version of a known brand appears unexpectedly, verifying it independently before entering information remains the safer default.

Sources and further reading

• Public Suffix List — Learn More
• ICANN: Internationalized Domain Names
• WHATWG URL Standard (userinfo and host parsing)