Domains, Subdomains, and URLs: Reading a Web Address Correctly

A web address can identify a site, resource, action, filter, and location inside a document.

Consider:

https://docs.example.com:443/guides/networking?id=5#dns

This is a URL, not merely a domain.

A domain is a hierarchical name. A URL is a complete reference describing how and where to access a resource.

Reading its components accurately helps with development, debugging, and security.

Scheme

The scheme appears before ://:

https

It identifies how the resource should be accessed.

Examples:

• https
• http
• file
• mailto
• ftp

The scheme influences default port, security behavior, and client handling.

Not every scheme uses two slashes, but HTTP URLs do.

Host

The host in the example is:

docs.example.com

It can be:

• Domain name
• IPv4 address
• Bracketed IPv6 address

The browser uses DNS when a domain must be resolved to network addresses.

The host identifies where to connect, though proxies and load balancers can route the request onward internally.

Registered domain and subdomain

In:

docs.example.com

com is a top-level domain, example.com is the commonly registered domain, and docs is a subdomain label.

The registrable boundary is not always one label plus TLD. For names under structures such as co.uk, public-suffix rules determine where registration can occur.

Browsers use a maintained public suffix list for cookie and security behavior.

Any number of subdomain levels can exist:

api.eu.example.com

Subdomains can represent teams, regions, environments, or services, but naming does not guarantee physical separation.

Port

The explicit port in the example is:

443

HTTPS defaults to TCP port 443, so it is usually omitted.

These are equivalent in ordinary cases:

https://example.com/
https://example.com:443/

A non-default port must normally be included:

http://localhost:3000/

The port is part of the browser's origin security concept.

Path

The path is:

/guides/networking

It identifies a resource within the server's URL space.

It does not need to match a physical file.

A web application may route:

/users/42

to code that queries a database and generates a response.

Paths are case-sensitive in URL standards, although a particular server can choose case-insensitive behavior.

Query string

The query begins after ?:

id=5

Multiple parameters commonly use &:

?category=networking&page=2

Query parameters can express:

• Filters
• Pagination
• Search
• Tracking
• Optional behavior

Their meaning is defined by the application.

Order and repeated keys may matter depending on server logic.

Fragment

The fragment begins after #:

#dns

It identifies a location or client-side state within the resource.

For normal HTTP navigation, the browser does not send the fragment to the server.

It can:

• Scroll to an element with a matching identifier
• Select a client-side route
• Preserve application UI state

The application can read it through browser APIs.

A concrete breakdown

For:

https://shop.example.com:8443/products/keyboard?color=black#reviews

The browser resolves the host, connects to port 8443, requests the path and query, then handles the fragment locally.

URL encoding

URLs use a restricted syntax. Characters outside permitted forms are percent-encoded as bytes.

A space may appear as:

%20

Non-ASCII text is encoded into bytes, commonly UTF-8, then percent-encoded.

Encoding and decoding must happen at the correct component level.

Double decoding can turn harmless text into path separators or control characters, creating security problems.

Use structured URL libraries rather than manual string concatenation.

Relative URLs

A relative URL omits some components and is resolved against a base URL.

From:

https://example.com/guides/start

these references mean:

images/map.png     → /guides/images/map.png
/images/map.png    → /images/map.png
../about           → /about

Protocol-relative URLs such as //example.com/path inherit the scheme, but explicit HTTPS URLs are generally clearer.

Relative URLs make sites portable across environments.

Origin

For browser security, an origin is approximately:

scheme + host + port

These are different origins:

https://example.com
http://example.com
https://api.example.com
https://example.com:8443

Browsers restrict how one origin reads another origin's data.

The path does not change origin. /app and /admin on the same scheme, host, and port share an origin unless additional application controls separate them.

Domain ownership and URL deception

To identify the controlling domain, read the host from right to left and understand the public suffix.

In:

https://paypal.example-attacker.com/

the registered domain is example-attacker.com; paypal is only a subdomain chosen by that owner.

Also watch for:

• Misspellings
• Similar-looking Unicode characters
• Username syntax before @
• Very long hosts
• Misleading path text

The lock icon does not validate that the brand name is the one you intended.

Common misunderstandings

"The domain is the entire URL"

It is only the host's naming portion. The URL also includes scheme and can include port, path, query, and fragment.

"The path must be a file on disk"

Applications can generate resources dynamically and map paths through routing rules.

"The fragment is sent to the server"

Browsers normally keep it client-side for HTTP requests.

"Any name containing a trusted brand belongs to that brand"

Attackers can place arbitrary words in subdomains or paths of domains they control.

Knowledge check

The one idea to remember

A domain names a host within DNS; a URL combines scheme, host, and resource-specific components into a complete reference.

Read each component separately, especially the registered domain, port, query, and origin.

Next, we will examine the client-server roles behind a web request and many other network applications.