Domain vs URL: What Is the Difference?

A domain is the name, while a URL is the full address used to reach a resource. In https://example.com:8443/docs?id=4, example.com is the domain, but the URL also tells the client to use HTTPS, connect to port 8443, request /docs, and send a query parameter.

The basic difference between a domain and a URL

I still see domain names and URLs treated as if they were interchangeable, especially when someone is troubleshooting a site at an inconvenient hour. They are related, but they answer different questions. A domain is a human-readable name used in DNS. A URL is the complete address that tells a client how to reach a resource.

For example, example.com is a domain name. https://example.com/blog?v=2#dns is a URL. The example.com part is the host’s domain; the URL also carries the scheme, path, query string, and fragment.

This distinction becomes useful when you configure DNS, TLS certificates, redirects, and a web server. DNS resolves a hostname to an IP address or returns other record types. A URL tells the client which scheme to use and which resource to request from that host.

Start here – When you inspect an address, separate the host from the scheme, port, path, query string, and fragment. That small habit prevents several layers from getting mixed together.

What parts make up a URL?

URL syntax follows the general URI structure described in RFC 3986. A browser address can look like this:

https://user:password@www.example.com:8443/store/product?id=42&color=blue#comments

Each part has its own job:

https://example.com/ is a valid URL, and its domain is example.com. If no port is written, the client normally uses the scheme’s default port: TCP 80 for HTTP and TCP 443 for HTTPS.

Some clients accept a username and password in a URL, but I avoid it. URLs can turn up in browser history, proxy logs, and web-server logs. Depending on the request and software involved, the URL may also appear in a referrer value.

I made this mistake years ago while testing an internal service: I pasted a URL containing a temporary token into a support ticket. The token was short-lived, but the lesson was not. Keep credentials and secrets out of URLs.

Use instead – Put the site behind HTTPS and use a separate authentication mechanism for administrative access.

What is a domain, and how does it work?

A domain is a name within the DNS hierarchy. DNS can use that name to return IPv4 and IPv6 addresses, mail destinations, verification data, aliases, and other records.

If we split www.example.com into labels:

• www: A label commonly used as a hostname or subdomain.
• example: The second-level part of the domain name.
• com: The top-level domain, or TLD.

The dot to the right of the name represents the DNS root. The fully qualified form can technically be written as www.example.com.; most people leave the final dot out.

Domain registration and web hosting are separate services. Registering a domain gives you control over the name and its delegation. A VPS or hosting account provides the infrastructure where the application and its data run.

A working setup normally involves a registrar, authoritative nameservers, and the required DNS records. A website commonly needs an A or AAAA record, email needs an MX record, and domain verification often uses a TXT record.

dig +short example.com A displays the A record, while dig +short example.com AAAA displays the IPv6 record. Empty output may mean the record is absent or that the resolver returned no answer. It does not prove that the web server is down.

That last distinction has saved me more than once. When a customer reported a dead website, I initially looked at Nginx logs before checking DNS. The logs were quiet because the request was never reaching the server.

Check first – When a site cannot be reached, inspect its A, AAAA, and CNAME records with dig +short before combining DNS and HTTP into one guess.

How can you tell a domain from a URL?

Read the address from left to right. Identify the scheme, isolate the host, and then look at everything after the host. The host can contain a domain or a hostname under that domain. The path, query, and fragment are not part of the domain.

Here is the detail that often matters in production: blog.example.com and example.com may belong to the same DNS zone, but they are separate hostnames. They can have different DNS records and can point to different IP addresses.

The same applies to example.com, www.example.com, and m.example.com. A web server, TLS certificate, and redirect rule can evaluate each one separately.

The https:// at the beginning of a URL is not the domain. It is the scheme. The domain is part of the host, while the URL describes the complete request address.

Short version: name and address are not the same thing.

Are domain, hostname, and URL the same thing?

They overlap, but they are not synonyms.

• Domain: A name or namespace within the DNS hierarchy. Example: example.com.
• Hostname: A name identifying a particular machine or service on a network. Example: vps01.example.com.
• FQDN: A hostname written with its complete DNS hierarchy. With the root dot included, it is vps01.example.com..
• URL: An address combining a scheme, host, port, and resource path. Example: https://vps01.example.com:8443/panel.

vps01.example.com can be a hostname. The same text can be the host portion of a URL, but it is not a complete URL until a scheme is included.

A DNS record and a web URL belong to different layers. An A record maps a hostname to an IPv4 address. An HTTP request carries the host and path from the URL to the web server. Nginx can use the Host header to select the correct virtual server when several sites share one IP address.

This is how several sites can live on one VPS. They may all point to the same IP, while Nginx chooses a different document root or application upstream based on the hostname.

One warning: the Host header is not, by itself, an authentication mechanism. Your application still needs proper access control.

How do HTTPS, DNS, and redirects relate to domains and URLs?

HTTPS is not a domain. During the TLS connection, the client validates a certificate for the hostname it selected. A certificate for example.com does not automatically cover www.example.com; the certificate must include that name or an appropriate wildcard.

When a browser opens https://example.com/product, the process roughly looks like this:

1. DNS resolution: The client looks up an A or AAAA record for example.com.
2. Connection: HTTPS normally uses TCP port 443. With HTTP/3, QUIC can use UDP port 443.
3. TLS validation: The certificate, hostname, and validity period are checked.
4. HTTP request: The host and /product path are sent to the server.
5. Application response: The server returns content, an error, or a redirect such as 301 or 302.

A redirect can change the URL’s domain without changing DNS. If http://example.com redirects to https://www.example.com/ with a 301 response, the DNS record has not necessarily changed. The web server or CDN issued the redirect.

During a domain migration, DNS caches and TTL values can cause different resolvers to return different answers for a while. Do not check only in a browser. Test the authoritative nameserver and public resolvers separately. The post What Is DNS Propagation? How Long Does It Take? explains this caching behavior in more detail.

When moving a site from HTTP to HTTPS, check the 301 redirect, canonical URL, certificate coverage, and absolute URLs generated by the application together. What Is a 301 Redirect? An SEO Implementation Guide covers the practical use of permanent redirects.

Test separately – Check the DNS answer, TLS certificate, and HTTP status code as different layers when investigating a redirect problem.

Testing domains and URLs from the command line

A browser can hide the original problem with caches, extensions, and browser-specific behavior. I usually start in a terminal. It is less pretty, but the output is honest.

dig +short example.com A
dig +short www.example.com CNAME
curl -I https://www.example.com/

The first two commands inspect DNS records. curl -I requests only the HTTP headers. You may see status codes such as HTTP/2 200, 301, 302, or 404. A 301 or 302 means the request reached a server, but that server sent the client somewhere else.

Use -L to follow and display a redirect chain:

curl -IL https://example.com/

This shows the headers from each redirect step. Two or three unnecessary redirects add latency and can cause cookie or canonical-URL problems in some applications.

To see which resolver is answering:

dig example.com A
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

The first query uses the resolver configured on your system. The other two query specific public resolvers. If the answers differ, inspect TTL, cached data, and the authoritative nameserver configuration. dig +short is easier to read; for deeper troubleshooting, keep the full output.

You can also test a hostname against a specific IP while preserving the hostname used for TLS and HTTP:

curl --resolve example.com:443:203.0.113.10 -I https://example.com/

--resolve creates a temporary IP mapping for the specified host and port. The request still uses example.com, which makes it useful for testing a staging IP without changing public DNS.

I keep a similar command ready when testing changes in my Proxmox lab. It has saved me from changing DNS just to discover that the Nginx virtual-host rule was the real problem. I once changed the wrong test record anyway, because I copied the hostname from an old note instead of checking it with hostname. The command was correct; my target was not.

My order – Check DNS with dig, then verify HTTP and redirects with curl -I.

Common domain and URL mistakes

One frequent mistake is treating the path as part of the domain. In example.com/blog, the domain is example.com and the path is /blog. DNS does not receive /blog; it resolves only the host.

Another mistake is assuming that www and the apex domain are automatically identical. A CNAME may exist for www.example.com, while example.com needs its own A or suitable provider-specific record. A CNAME at the apex depends on support for mechanisms such as ALIAS or ANAME.

A third mistake is treating query parameters as access control. A URL such as /download?file=report.pdf does not authorize anyone to download the file. The application still needs session and permission checks.

A fourth mistake is ignoring URL encoding. Spaces, non-ASCII characters, and special characters such as & must be encoded correctly. The form shown in a browser’s address bar may not be identical to the form parsed by the application.

A fifth mistake is treating http and https as the same origin. An origin is defined by the scheme, host, and port. https://example.com and http://example.com differ by more than one character: their encryption and browser security behavior are different.

With a CDN, the URL can remain unchanged while DNS returns a CDN edge IP. As explained in What Is a CDN? How It Speeds Up Websites, adding a distribution layer between the visitor and the origin changes the request path, not the meaning of the domain.

Do not fix these problems with a broad rewrite rule or a quick chmod 777. That only changes the symptom, and sometimes creates a new problem.

A short decision table for domains and URLs

This table is a quick way to decide which layer deserves your attention:

The short version is this: a domain is the named part of a URL’s host, while a URL is the complete address describing how to reach a resource on that host. Not every domain is a URL. A URL also does not need a registered domain; it can use an IP address or localhost.

For example, http://127.0.0.1:8080/test is a valid URL, but it contains no registered domain. Its host is an IPv4 address. Likewise, file:///home/user/notes.txt is a URL form without a web domain.

Keep this habit – Use “domain” for the name itself and “URL” for the complete address, including its scheme and resource path. When a site misbehaves, inspect those pieces one at a time.

Check These Before Troubleshooting

• Separate the domain or hostname from the complete URL.
• Check A, AAAA, and CNAME records with dig.
• Confirm the URL scheme and port.
• Verify that the TLS certificate covers the requested hostname.
• Inspect HTTP status codes with curl -I.
• Follow redirect chains with curl -IL.
• Test a staging IP with curl –resolve before changing public DNS.

Frequently Asked Questions

Sources

• IETF RFC 3986 – Uniform Resource Identifier Syntax — rfc-editor.org
• IETF RFC 9110 – HTTP Semantics — rfc-editor.org
• ICANN – Domain Name System Glossary — icann.org
• IANA – Service Name and Transport Protocol Port Number Registry — iana.org