URLs, URIs, and URNs: What's the Difference?

Every link you've ever clicked is a URL. But URLs have a problem: they're promises about location, and locations change.

A website moves to a new domain. A company reorganizes its file structure. A server gets decommissioned. The URL breaks. The resource still exists somewhere—you just can't find it anymore.

This is the problem URNs were designed to solve. And understanding the difference between URLs, URNs, and their parent category URIs reveals something fundamental about how we identify things on the Internet.

URI: The Parent Category

A URI (Uniform Resource Identifier) is any string that uniquely identifies a resource. It's the umbrella term.

URIs come in two flavors:

• URLs identify resources by location
• URNs identify resources by name

Every URL is a URI. Every URN is a URI. But they solve different problems.

URLs: Identification by Location

A URL (Uniform Resource Locator) tells you three things: the protocol (how to access it), the domain (where to find it), and the path (which specific resource).

https://www.connected.app/support/topics/dns
  │            │                    │
protocol    domain                path

URLs are instructions. When you type one into a browser, you're saying: "Use HTTPS to connect to this server and request this specific resource." The browser knows exactly what to do.

Common URL examples:

• https://www.example.com/page.html — a web page
• ftp://files.example.com/doc.pdf — a file via FTP
• mailto:support@connected.app — an email address
• tel:+1-555-123-4567 — a phone number

All of these specify location and access method. That's what makes them URLs.

URNs: Identification by Name

A URN (Uniform Resource Name) identifies a resource by name within a namespace. It says what something is, not where it is.

urn:isbn:978-0-134-68599-1

This URN identifies a specific book by its ISBN. Walk into any bookstore on Earth, give them this number, and they know exactly which book you mean. The identifier works regardless of which shelf holds it, which warehouse stores it, or which website sells it.

More URN examples:

• urn:isbn:978-0-134-68599-1 — a book
• urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 — a unique identifier
• urn:ietf:rfc:3986 — an RFC document

The tradeoff is clear: a URN identifies something permanently, but it doesn't tell you how to get it. You need a separate system—a library catalog, a bookstore, a resolver service—to turn that identifier into something you can actually retrieve.

Why the Difference Matters

A URL is a promise about where something lives. A URN is a promise about what something is. Promises about location break when things move. Promises about identity don't.

This matters when you're building systems that need to reference resources across time and context:

• Academic papers use DOIs (a type of URN) because papers get cited for decades, and journal websites reorganize constantly
• Books use ISBNs because the same book might be sold by thousands of retailers
• Database records use UUIDs because the record might move between systems

For everyday web browsing, URLs work fine. For persistent identification that needs to survive relocation, reorganization, and the passage of time, you need URNs.

Why People Use These Terms Interchangeably

In practice, almost every URI you encounter on the web is a URL. When someone says "URI" they usually mean "URL." This isn't wrong—it's just imprecise.

The distinction only matters when you're working with persistent identifiers, designing APIs that need stable references, or building systems where resources might move but references to them shouldn't break.