A web address is built from several distinct parts, and figuring out which part actually identifies the organization behind it takes more than a simple rule like “count the dots.” That shortcut works for a plain address like example.com, but it breaks down for addresses ending in .co.uk, .com.au, or dozens of other multi-part endings — and getting it wrong is exactly what makes some deceptive addresses convincing. This guide focuses specifically on ordinary HTTP and HTTPS web addresses, which is what you will encounter clicking links and typing addresses in a browser; other URL schemes (for email, files, or other protocols) share some structure but are outside what is covered here. This guide walks through the real structure: the hostname, the registrable domain, the subdomain, and the public suffix, with worked examples of each.

The parts of a URL, from the outside in

Take a full address apart piece by piece: https://user:[email protected]:8443/login/reset?token=8f2a&lang=en#step2 — this example deliberately includes every optional part; most everyday links you encounter will omit several of these.

Part	In the example	Who controls it
Scheme	https://	Indicates an encrypted connection. See Why the HTTPS Padlock Does Not Guarantee a Website Is Safe — encryption does not by itself indicate who is on the other end.
Authority	user:[email protected]:8443	Everything between // and the next /, ?, or # — made up of optional userinfo, the host, and an optional port.
Userinfo	user:pass	An optional, largely obsolete username/password field preceding an @ symbol. Set by whoever constructs the link, not verified by anything — see below.
Host	accounts.example.com	The domain name or IP address the browser actually connects to. Made of a subdomain plus a registrable domain, when the host is a domain name.
Port	8443	An optional number identifying a specific network channel on the host. Ordinary web browsing omits this, using the scheme’s default port instead.
Subdomain	accounts	Chosen freely by whoever controls the registrable domain. Can be set to anything, including a misleading brand name.
Registrable domain	example.com	The label registered with a domain registry, relative to the public suffix. This is the identity that matters most for comparison purposes — see the limitations below on what it does and does not prove.
Path	/login/reset	A page location, again set entirely by whoever controls the domain.
Query string	?token=8f2a&lang=en	Extra parameters — see Tracking Parameters in Links: UTM, Referral, and Click IDs Explained.
Fragment	#step2	A reference to a specific location within the page, handled by the browser itself and not ordinarily sent to the server as part of the request.

Hostname vs. registrable domain: why they are not the same thing

The host is what the browser actually connects to — usually a domain name, though it can also be a raw numeric IP address, which has no registrable domain or subdomain structure at all; the guidance in this article applies to domain-name hosts specifically. When the host is a domain name, the registrable domain (sometimes written eTLD+1, meaning “one label beyond the effective top-level domain”) is the label immediately preceding the public suffix, together with the public suffix itself. It is best understood as a parsing and comparison concept, not a claim about legal purchase or contractual registration — it identifies which portion of the address to compare against a known-correct domain, not who registered it or when. Everything to the left of the registrable domain in the host is a subdomain, freely chosen by whoever controls the registrable domain; the presence of a particular word in the subdomain position does not by itself establish who actually operates the content served there, since subdomains can also be delegated to a separate hosting provider or service.

Why counting dots does not work

A common shortcut says: take the last two dot-separated labels, and that is the domain. For accounts.example.com, that gives example.com — correct. But apply the same two-label rule to login.example.co.uk and you get co.uk, which is not a registrable domain at all — it is a public suffix, a shared ending under which many unrelated organizations register names, similar to how many unrelated sites end in plain .com. The actual registrable domain in that address is example.co.uk — three labels, not two, because .co.uk is a two-label public suffix. The same problem applies to shop.example.com.au, where the registrable domain is example.com.au (again three labels, because .com.au is the public suffix). There is no fixed number of labels that works for every address, which is exactly why a simple dot-counting rule is unreliable.

What a public suffix actually is

According to the Public Suffix List project, a public suffix is an ending under which internet users can directly register names — common single-label examples include .com and .org, while common multi-label examples include .co.uk and .com.au. The list itself mixes two kinds of entries: registry-controlled suffixes assigned by the domain name system’s formal registry structure, and privately operated suffixes that some hosting and platform providers have added for their own services, so that customers’ sites on a shared platform are treated as separate registrable domains from one another rather than all being lumped under the platform’s own domain. Because there is no algorithm that derives any of this from the domain name’s text alone, browsers and other software rely on this maintained reference rather than guessing from dot count.

A deceptive subdomain, applying the same method

Now apply the same reasoning to an address designed to mislead: https://example.com.login-security.test/secure. It is tempting to read this left to right and see “example.com” and assume that is the domain. It is not. Working from the public suffix inward: .test is the ending here — a top-level domain reserved by the IETF specifically for testing and documentation purposes and guaranteed never to be assigned to a real registrant, which is why this guide uses it for exactly that purpose — so the registrable domain is login-security.test. Everything before that — including the text example.com — is just a subdomain label chosen by whoever controls login-security.test. This is a well-documented deceptive pattern: placing a familiar brand name earlier in the address, in a position that has no bearing on who actually controls the domain. See Lookalike Domains and Homograph Attacks: What to Check for more patterns like this one, and How to Tell Whether a Link Is Safe Before You Click for a general link-checking routine.

A different trick: text before the @ symbol

As the parts table above shows, the authority section of a URL can technically include userinfo — text intended for a username (and historically a password), separated from the actual host by an @ symbol, in the form scheme://userinfo@host/path. For example, in https://[email protected]/secure, everything before the @ symbol — including the text “example.com” — is userinfo, not the host. The actual host your browser connects to is login-security.test, exactly as if the userinfo portion were not there at all. Because most sites do not use this feature, a familiar brand name placed before an @ symbol is a strong deceptive signal on its own, relying on the reader assuming the text before the @ is the domain rather than an unrelated, largely vestigial field. Some modern browsers flag or restrict this pattern; not all do, and it is worth recognizing on sight regardless of what a particular browser does with it.

Practical steps for reading an address without special tools

1. Find the host: within the authority section (after //), skip past any userinfo (text ending in an @ symbol — see below) and drop any trailing port number (a colon followed by digits) — what remains, up to the next /, ?, or #, is the host.
2. Look at the ending. If it is a plain, single well-known ending like .com, .org, or .net, the registrable domain is usually the last two labels.
3. If the ending looks like a country code (two letters, such as .uk, .au, .jp) check whether it is preceded by a second-level label like co, com, gov, or org — country-code endings very often use these multi-label public suffixes, so the registrable domain is then the last three labels, not two.
4. When you are not sure, a lookup tool built on the actual Public Suffix List will give a definitive answer — this is the same reference browsers themselves use, rather than a guess based on label counting.
5. Whatever you determine to be the registrable domain, that is the identity to evaluate — not any brand-sounding word that appears earlier in the address.

International domain names, Punycode, and homograph risk

Domain names can contain characters beyond basic Latin letters, through a system called Internationalized Domain Names (IDN). Because the underlying domain name system only handles a specific limited character set, browsers convert these international characters into a representation called Punycode (visually recognizable by an xn-- prefix) behind the scenes. This system exists for a legitimate reason — it lets domains use scripts appropriate to their language — but it also creates a known risk called a homograph attack: characters from different scripts can look identical or nearly identical to Latin letters at typical reading sizes. Browser vendors have implemented various display policies intended to reveal Punycode instead of the deceptive rendered form under certain mixed-script conditions, but these protections are not comprehensive across every browser, script combination, and font, so visual similarity between two addresses is not something to rule out just because a domain “looks right.” See Lookalike Domains and Homograph Attacks: What to Check for how this shows up in practice, including simpler, non-IDN tricks like substituting “rn” for “m”.

What HTTPS does and does not tell you here

The scheme at the start of the address — https:// versus http:// — indicates whether the connection to that specific hostname is encrypted. It says nothing about who controls the registrable domain or whether that domain is trustworthy; an encrypted connection to a deceptive domain is still an encrypted connection to a deceptive domain. See the companion guide on what the padlock icon does and does not guarantee for a full explanation of that distinction.

Limitations

Manually working out a registrable domain using the steps above is a useful skill, but the Public Suffix List itself is a maintained, evolving reference, not a fixed mathematical rule — new public suffixes are added over time as new registries adopt multi-label registration policies, so an unfamiliar-looking multi-label ending is not automatically suspicious just because it is unfamiliar to you. Likewise, correctly identifying the registrable domain tells you who is nominally responsible for that address; it does not by itself tell you whether that party is legitimate, whether the domain has been compromised, or whether the specific page you are viewing is safe to enter information into.

Frequently asked questions

Is there a simple rule that always works?

No single fixed rule (like “the last two labels”) works for every address, because public suffixes vary in length. The reliable method is identifying the public suffix first, then taking one label beyond it as the registrable domain — which is exactly what the Public Suffix List is designed to answer definitively when you are unsure.

Why does this matter for phishing specifically?

Because deceptive addresses are often constructed specifically to exploit an incorrect reading of the hostname — placing a trusted brand name in a subdomain or path position rather than the registrable domain. See How to Spot a Phishing Link in an Email or Text Message for how this pattern shows up in messages.

Do mobile browsers show the full hostname?

Space is limited on small screens, and some mobile browsers truncate long addresses in the address bar. Tapping the address bar typically reveals the full text, which is worth doing before trusting an unfamiliar link.

Sources and further reading

• Public Suffix List — official project site
• Public Suffix List — Learn More (background and browser usage)
• IETF RFC 2606 (BCP 32): Reserved Top Level DNS Names
• CISA: Avoiding Social Engineering and Phishing Attacks