System Design Fundamentals

0% completed

URL vs. URI vs. URN

On This Page

Three Terms, One Family

URI

URL

The Parts of a URL

Special Characters

Absolute and Relative URLs

URN

URL vs. URN

Why This Matters in System Design

Key Takeaways

Practice Questions

You send a friend this link to a product:

https://shop.example.com/products/42?color=red#reviews

Your friend opens it and sees the reviews section of the red version of that product. Every part of the link had a purpose. One part told the browser how to connect, one told it which server to ask, and one told it which product to show.

This lesson explains each part of a link like this one. It also explains three terms that people often mix up: URI, URL, and URN.

Three Terms, One Family

The three terms are related. One is the general term, and the other two are special kinds of it.

A URI (Uniform Resource Identifier) is any string that identifies a resource. It can identify the resource by its location, by its name, or by both.
A URL (Uniform Resource Locator) is a URI that also tells you how and where to reach the resource.
A URN (Uniform Resource Name) is a URI that gives the resource a permanent name, without saying where it is.

A resource here means anything that can be identified: a web page, an image, a file, a book, or a person's account.

URI is the general term, with URL for identifiers that locate a resource and URN for identifiers that only name it

All URLs and URNs are URIs. But not every URI is a URL or a URN.

URI

A URI identifies a resource. It is the most general of the three terms.

Every URI follows the same basic pattern. It starts with a scheme, followed by a colon, and then the rest of the identifier.

scheme:rest-of-the-identifier

Here are a few URIs with different schemes.

https://www.example.com/about identifies a web page.
mailto:support@example.com identifies an email address.
urn:isbn:0451450523 identifies a book.

Each one identifies something. Only some of them tell you where that thing is.

URL

A URL is a URI that identifies a resource and describes how to get it, usually by its network location. A URL answers two questions: how to reach the resource, and where it is.

The Parts of a URL

Here is a full URL, with every optional part included.

https://shop.example.com:443/products/42?color=red&size=m#reviews

It has six parts.

Scheme (https). The protocol to use, like HTTP, HTTPS, or FTP.
Host (shop.example.com). The domain name of the server. The browser uses DNS to find the server's IP address from this name.
Port (443). The port on the server. It is usually left out, because each scheme has a default: 80 for HTTP and 443 for HTTPS.
Path (/products/42). Which resource on the server you want.
Query (?color=red&size=m). Extra options for the request, written as key=value pairs and separated by &.
Fragment (#reviews). A position inside the resource, like one section of a page.

A URL breaks into the scheme, host, port, path, query, and fragment, and only the fragment stays in the browser

The fragment is never sent to the server. The browser keeps it and uses it after the page loads, for example to scroll to the reviews section. So the server receives the same request with or without #reviews.

In short, a URL is made of a protocol, a domain name, and a path. It can also include query parameters and a fragment.

Special Characters

A URL can contain only certain characters. Spaces and many symbols must be written in a special form called percent-encoding. Each such character becomes a % sign followed by two hexadecimal digits.

For example, a space becomes %20. So a search for "red shoes" can appear as ?q=red%20shoes.

Absolute and Relative URLs

An absolute URL includes the scheme and host, like https://shop.example.com/images/logo.png.

A relative URL leaves them out, like /images/logo.png. The browser fills in the missing parts from the page it is on. Web pages use relative URLs for their own files, so the same page works on any domain.

URN

A URN is a URI that names a resource with a unique and permanent identifier. It does not say how to locate the resource. A URN answers only one question: what is this?

URNs follow this pattern.

urn:namespace:identifier

The namespace says which naming system the identifier comes from. Here are two examples.

urn:isbn:0451450523 identifies one book by its ISBN, the international book number.
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 identifies an object by a UUID, a 128-bit ID that is unique for all practical purposes.

The book's URN stays the same no matter where copies of the book are stored, or whether a copy exists online at all.

A URN cannot be opened directly. To get the resource, a system needs a resolver, which is a service that looks up a name and returns a current location. For example, a library system can look up a book's URN and return the file's current URL. If the file moves, only the resolver's record changes. The URN stays the same.

URLs describe where a resource is and can break when it moves, while URNs name a resource and need a resolver to find a current copy

URL vs. URN

	URL	URN
What it gives	How and where to reach a resource	A permanent name for a resource
Example	`https://example.com/books/42.pdf`	`urn:isbn:0451450523`
Can a browser open it?	Yes	No, it needs a resolver
If the resource moves	The URL can break	The URN still works
Is it a URI?	Yes	Yes

This table explains the sentence that often confuses people. Every URL is a URI, because locating a resource is one way of identifying it. Not every URI is a URL, because a URI can be a URN, which only names a resource and gives no location.

A note on everyday language. Almost every identifier you use on the web is a URL. So in practice, many people and web standards simply say "URL" for any web address. Technical specifications often use "URI" as the general term.

Why This Matters in System Design

The terms matter less than the ideas behind them. Three of those ideas come up often.

Stable identifiers in APIs. Suppose an API returns each order's full URL, like https://api.example.com/v1/orders/9001. Every client now depends on that host and path. If the API moves to /v2, stored links break. Returning a stable ID, like 9001, lets clients build the URL when they need it. This is the same idea as a URN: a name that does not change when the location does.

Cache keys. Caches and CDNs usually store each response under its full URL. So ?color=red&size=m and ?size=m&color=red can be stored as two different entries, even though they mean the same thing. Keeping query parameters in a fixed order makes caching work better.

Never put secrets in a URL. URLs are saved in browser history, server logs, proxy logs, and analytics tools, and they are easy to share by mistake. Passwords and API keys should go in request headers or the request body instead. If a link must contain a token, as in a password reset link, the token should work only once and expire quickly.

Key Takeaways

A URI (Uniform Resource Identifier) is the general term for any identifier of a resource, by location, name, or both.
A URL (Uniform Resource Locator) is a URI that says how and where to reach a resource.
A URL has a scheme, host, and path, and can also have a port, query parameters, and a fragment. The fragment is never sent to the server.
A URN (Uniform Resource Name) is a URI that names a resource permanently, like urn:isbn:0451450523, without giving its location.
All URLs and URNs are URIs, but not every URI is a URL or a URN.
In system design, prefer stable IDs over stored URLs. Also keep query parameters in a fixed order for caching, and keep secrets out of URLs.

A URL tells a browser where to go. A URN tells a system what something is, wherever it is. The next lesson is What Happens When You Type a URL into the Browser. It follows a URL from the address bar to a finished page, using every idea from this chapter.