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

Every link you've ever clicked is a URL. You've used thousands of them. They work so reliably that you've probably never thought about what they actually promise—or what happens when that promise breaks.

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.

URI: The Umbrella Term

A URI (Uniform Resource Identifier) is any string that uniquely identifies a resource. That's it. It's the parent category.

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: Where Something Lives

A URL (Uniform Resource Locator) tells you how to get something: the protocol, the domain, and the path.

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

URLs are instructions. "Use HTTPS. Connect to this server. Request this resource." The browser knows exactly what to do.

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: What Something Is

A URN (Uniform Resource Name) identifies a resource by name within a namespace. Not where it is. What it is.

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

This 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.

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 cost is obvious: a URN identifies something permanently, but it doesn't tell you how to get it. You need a separate system—a library catalog, a resolver service, a search engine—to turn that identifier into something you can actually retrieve.

The Core Difference

A URL is a promise about where. A URN is a promise about what.

Promises about where break when things move. Promises about what don't.

This shapes how systems get built:

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

For clicking links, URLs work fine. For references that need to survive relocation, reorganization, and time itself, you need URNs.

Why Everyone Conflates Them

Almost every URI you encounter on the web is a URL. When someone says "URI" they usually mean "URL." This isn't wrong—just imprecise.

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

For everyone else, the terms are interchangeable. And that's fine.