URL, Uri, and Urn: What's the Difference?

If somebody asks for the URL of a page, correcting them to "URI" will rarely improve the conversation. An ordinary HTTPS address is both. The interesting part is why the terms overlap, and why the neat diagram often used to explain them can promise more certainty than the standards do.

Identification and Access are Different Questions

Take the address https://example.com/catalogue/chair-42. In RFC 3986 terms, it identifies a resource and provides an access mechanism, so it is both a URI and a URL.

That doesn't guarantee a successful response. The server might be unavailable, the resource might require permission, or the address might return a not‑found response. A URL can still fail when you follow it.

A catalogue record may need a stable identifier even when the shop's public page moves. The identifier can stay the same, but a system still needs some way to find information about it; the name alone doesn't explain how every client should retrieve it.

I find that distinction useful in content modelling. "Which item is this?" and "Where should this link take a visitor?" are separate questions. Sometimes one value answers both. Sometimes treating them as one field makes a future migration unnecessarily awkward.

A Urn Has a Particular Syntax

RFC 8141, published in April 2017, defines URNs using the urn scheme. After urn: comes a namespace identifier and a namespace‑specific string. The namespace supplies the rules and meaning for the name.

The example namespace reserved by RFC 6963 makes urn:example:catalogue-item-42 a safe way to show the shape. A database value such as 42 doesn't become a URN just because it identifies a row inside one application.

URNs are intended for persistent naming independent of a resource's current location. That doesn't make every URN a browser address: resolution depends on the namespace and on services being available.

Persistence also needs responsible assignment and maintenance. Choosing a syntax with a reassuring acronym doesn't preserve a resource by magic. If an organisation reuses identifiers for unrelated things, its consumers still have a problem, however carefully the identifiers are formatted.

Names and Locations Can Overlap

The familiar diagram of separate URL and URN circles inside a URI circle is only an approximation. The W3C/IETF clarification in RFC 3305 explains why schemes do not always fit an exclusive naming‑or‑location category. An HTTPS address can be a persistent identifier, and a URN can have a resolution service; the syntaxes still aren't interchangeable.

For a publishing system, I would document whether an identifier survives a title change, whether an old address redirects, and whether consumers should store an internal ID or a public link. Those are the guarantees a caller needs.

Web‑Platform Documentation Often Just Says URL

The WHATWG URL Standard, as recorded in the December 2014 W3C draft, deliberately uses "URL" for the web‑platform parsing and API model. Its terminology doesn't preserve every distinction found in the older URI family of documents.

So context matters when reading a specification or reviewing a variable name. A browser API named URL isn't incorrectly named because the URI umbrella definition is broader. An IETF document using "URI" may be making a useful distinction of its own.

Follow the interface's vocabulary, then spell out any restriction the caller needs. If a field accepts only absolute HTTPS addresses, say so: "URI" alone doesn't impose that rule, and "URL" alone doesn't tell you which schemes are allowed.

In an API contract, a property named uri might be an opaque identifier, a relative reference, or an address intended for navigation. The name is a clue; documented meaning and validation rules do the real work. Renaming it without checking consumers isn't a terminology fix.

A Relative Reference Needs Context

The string /catalogue/chair-42 can link within a site, but it omits the scheme and host. A base address is needed to resolve it, so it doesn't identify one fixed global destination on its own.

A path‑relative value such as chair-42 depends on the base path too. Copy it into another document and it may lead somewhere else; the text stays the same, but the context changes.

A reference beginning // inherits the scheme from its base whilst supplying an authority. The article on protocol‑relative URLs covers the pattern and its drawbacks.

When checking a link, inspect the resolved destination as well as the original string. When designing a field, decide whether relative references are allowed and which base applies.

When a link fails, check its syntax, supported scheme, reachability, and permission separately. A parser can confirm the first; it can't answer the rest.