IP, Domain, and URL: What's the Difference?

You type https://example.com/articles?id=5 into your browser. Three different layers of internet addressing are at work in that single string. The URL is the full request. The domain is example.com. The IP is some number like 93.184.216.34 that the domain resolves to. These three concepts get conflated constantly — even by experienced developers in casual conversation.

This post clears them up: what each is, how they relate, and the practical differences that matter for code, debugging, and architecture.

IP Address

An IP address is a numerical identifier for a host on a network. Two flavors:

• IPv4: 203.0.113.5 — a 32-bit number written as four octets.
• IPv6: 2001:db8::1 — a 128-bit number written as eight groups.

IP addresses are how packets are routed. Every device on the internet has at least one IP. Every server you connect to has an IP.

IPs are assigned (by ISPs, cloud providers, RIRs), routable (BGP tells the internet how to reach them), and directly usable (you can type http://93.184.216.34 and it works if the server’s listening). They’re the physical-ish address.

For everything you might want to know about IPs, see everything you need to know about IP addresses.

Domain Name

A domain name is a human-friendly name that maps to one or more IP addresses. example.com, google.com, bbc.co.uk are all domains.

Domains are organized hierarchically:

• TLD — top-level domain. .com, .org, .co.uk.
• Second-level domain — example in example.com.
• Subdomain — www, api, mail in www.example.com, api.example.com.

A domain resolves to an IP via DNS. The DNS A record for example.com might be 93.184.216.34. The AAAA record (for IPv6) might be 2606:2800:220:1:248:1893:25c8:1946.

Domains are registered (you buy them from a registrar like Namecheap or Google Domains), resolved (DNS turns them into IPs), and memorable (compared to raw IPs). They’re a logical-naming layer on top of IPs.

For more on translating between domains and IPs, see how to find a domain’s IP.

URL

A URL (Uniform Resource Locator) is a full request specification. It identifies what you want and how to get it.

A typical URL:

https://www.example.com:443/articles/2024?id=5&sort=date#section-2
└──┬──┘ └─────┬──────┘ └┬┘└──┬──────┘ └──────┬──────┘ └───┬───┘
   │         │         │   │              │              │
 scheme    host       port path           query        fragment

• Scheme (https) — protocol to use.
• Host (www.example.com) — the domain (could also be an IP).
• Port (443) — TCP port, omitted when default.
• Path (/articles/2024) — what to ask for on the server.
• Query (?id=5&sort=date) — extra parameters.
• Fragment (#section-2) — client-side anchor; never sent to server.

URLs are requests, not addresses. They tell a server what you want. The URL includes the addressing layer (host) but adds protocol, path, parameters, and intent.

How They Relate

A complete picture:

URL          https://www.example.com/path
                       │
Domain          www.example.com
                       │ (DNS resolution)
                       ▼
IP                93.184.216.34
                       │ (routed via BGP)
                       ▼
Server hosting the resource

When your browser handles the URL:

1. Parse the URL into components.
2. Look up the host via DNS to get the IP.
3. Connect to the IP on the port (443 for HTTPS).
4. Establish TLS using the host name (SNI).
5. Send an HTTP request for the path/query.
6. Receive the response.
7. Apply the fragment (scroll to the section).

The URL is the request. The domain is the addressable thing being requested. The IP is where the packets go.

Common Confusions

”Pinging a URL”

You can’t ping a URL. You can ping a host. ping https://example.com/page doesn’t make sense; ping example.com does. The path, query, and scheme aren’t network-layer concepts.

”The IP of a website”

A website might have multiple IPs (load balancing, anycast). A “website” is fuzzy — domain? URL? Service? Be specific.

”The IP of a domain”

A domain has one or more A records (and AAAA records). They might change over time (DNS-based load balancing) or vary by region (geo-DNS). “The IP of a domain right now” is what dig example.com returns at this moment.

”URL” vs “URI”

A URI (Uniform Resource Identifier) is a superset of URL. URIs include URLs and URNs (Uniform Resource Names like urn:isbn:...). In practice “URL” is what people mean.

”Domain” vs “host”

Often interchangeable. Strictly: a host is www.example.com; the domain is example.com. Subdomain is www. People conflate “host” and “domain” all the time.

Direct IP vs Domain Access

You can usually type an IP directly into a browser:

http://93.184.216.34/

This works for plain HTTP. For HTTPS it gets complicated:

• The server uses SNI (Server Name Indication) to know which certificate to serve.
• Without a hostname in the request, it uses the default certificate.
• That default cert is probably not valid for “93.184.216.34” specifically.
• Browser shows “your connection is not private” because the cert doesn’t match what you typed.

For modern HTTPS, you almost always want to use a domain. The IP-direct workflow is mostly for debugging or accessing services on private networks.

Subdomain vs Path

A frequent design question: should the API be api.example.com or example.com/api?

Subdomain (api.example.com)

• Independent DNS record; can point to different infrastructure.
• Different SSL certificate possible.
• Cleaner separation; sometimes CORS becomes relevant.
• Separate cookie scope by default.

Path (example.com/api)

• Same origin; no CORS issues with the main site.
• Same cookie scope; SSO is automatic.
• All traffic goes through the same domain/edge.

Both are valid. Pick based on architecture (is the API genuinely separate?) and operational needs (different teams managing each?).

Internationalized Domains

Domains can include non-ASCII characters: 例え.テスト, 日本語ドメイン.com. These are encoded with Punycode for DNS:

日本語ドメイン.com → xn--eckwd4c7c5176a.com

DNS and IP layers only see the Punycode. Browsers convert for display. This matters for:

• Phishing — Lookalike characters in Unicode (the letter “о” in Cyrillic vs “o” in Latin). Some browsers warn about mixed-script domains.
• Logging — Log domains in canonical form (either Unicode or Punycode consistently).
• Validation — Don’t reject domains because they contain non-ASCII; use proper Punycode-aware libraries.

URL Encoding

Special characters in URLs must be encoded:

• Space → %20 or + (in query strings)
• & in a value → %26 (otherwise it’d start a new parameter)
• # → %23 (otherwise it’d start a fragment)

https://example.com/search?q=hello%20world&cat=test

Use library functions (encodeURIComponent in JS, urlencode in Python). Don’t roll your own.

Geolocation: Different for Each Layer

A subtle but important point about location:

• IP geolocation — gives the IP’s location. Real address, somewhat fuzzy. See how to geolocate an IP.
• Domain location — registrants have a registered country; sometimes informative.
• URL — has no location of its own; only the IP does.

When tooling shows “this URL is in Germany,” what it really means is “the IP that this URL’s domain resolves to is geolocated to Germany.” Three layers of indirection in one phrase.

TL;DR

• IP = numerical network address. 93.184.216.34 or 2001:db8::1.
• Domain = human-friendly name. example.com. Resolves to an IP via DNS.
• URL = full request specification. Scheme + host + port + path + query + fragment.
• You ping a host, not a URL. Path/query/scheme are not network concepts.
• A domain can have multiple IPs; “the IP” is “what DNS returns right now.”
• HTTPS to a raw IP usually fails because the cert isn’t for the IP.
• Subdomain vs path for APIs is a design choice with operational implications.
• Punycode-encode non-ASCII domains for DNS.
• URL-encode special characters in URLs.

Once you internalize the three layers — IP at the network layer, domain at the naming layer, URL at the application layer — most internet plumbing makes sense. Most confusion comes from conflating them. For deep dives on each layer, see everything you need to know about IP addresses, how DNS lookup works, and how to find a domain’s IP. For tools to query each layer, the Ip2Geo tools cover IP lookup, DNS lookup, and domain to IP in one place.