URL vs URI vs URN

A URI is just a text string that a parser splits into a scheme plus scheme-specific parts; whether that string also tells a machine how to fetch the bytes (a URL) or only names the resource permanently (a URN) depends entirely on whether the scheme carries a resolvable location. URI is the syntactic superset; URL and URN are two roles a URI can play.

The mental hook: a URL answers How (protocol) and Where (location). A URN answers only What (a persistent name). A URI is the umbrella that covers both.

Worked example: parsing a real URL (RFC 3986)

Take a fully loaded URL and run the generic-syntax split. Every URI decomposes as scheme ":" ["//" authority] path ["?" query] ["#" fragment], and the authority further splits into [userinfo "@"] host [":" port]. Trace it component by component:

https://ada@shop.example.com:8443/products/42?ref=email&sort=price#reviews

Now parse the URN urn:isbn:0451450523: scheme urn, namespace identifier (NID) isbn, namespace-specific string (NSS) 0451450523. There is no host, no port, no path — nothing tells a machine where the book lives. It is a name, not an address. To turn it into bytes you must hand it to a resolver that maps the name to a current location.

Pitfalls

• Assuming a URN is fetchable. urn:isbn:0451450523 cannot be dereferenced by a browser. It uniquely identifies a book but says nothing about where a copy lives; you need a resolver service (for DOIs, the doi.org proxy; for ISBNs, a library catalog) to turn the name into a current URL. Uniqueness is not resolvability.
• Expecting the server to see the fragment. The #reviews part is stripped by the client and never sent in the HTTP request line. Building server logic that reads the fragment (e.g., for routing or analytics) silently fails — it must be captured client-side and forwarded as a query param if the server needs it.
• Calling everything a URL. In casual speech "URL" is fine, but in specs and code the correct general term is URI (and modern browsers implement the WHATWG URL Standard, which diverges from RFC 3986 on edge cases like backslash and whitespace handling). mailto:ada@x.com, tel:+18005551234, and data:text/plain,hi are URIs with no locatable host.
• Forgetting percent-encoding. Reserved characters (space, ?, #, &, /) must be encoded in each component or the parser mis-splits the URI. A raw space in a path yields a broken or ambiguous request; it must become %20.
• Treating relative references as URIs that identify on their own. /products/42 is a relative reference — it only resolves against a base URI. Storing it as a stable identifier breaks the moment the base changes.
• Using an un-normalized URL as a cache key or an authorization key. Two URLs that differ only in trailing slash, host case, percent-encoding, or query-parameter order (/a?x=1&y=2 vs /a?y=2&x=1) name the same resource but are distinct strings. Un-normalized, they fragment a cache into duplicate entries (lower hit rate, stale copies), and — worse — an authorization check written against one spelling can be bypassed by requesting an equivalent spelling. Normalize per RFC 3986 §6 (lowercase scheme/host, decode unreserved octets, remove dot-segments) — and, as an application-level cache-key rule beyond the RFC, canonicalize query order too, since RFC 3986 treats ?x=1&y=2 and ?y=2&x=1 as different URIs even though your handler treats them the same — all before the string is used as a key.

Two parsers, one string

The WHATWG/RFC divergence mentioned above is not academic — here is one string parsed two ways:

https://good.example\@evil.example/

A WHATWG-conformant browser treats backslashes in special-scheme URLs as forward slashes, so the authority ends at the backslash: host = good.example, path = /@evil.example/. A strict RFC 3986 split never treats \ as a delimiter, so a library following that grammar reads the authority as good.example\@evil.example and — splitting userinfo at the @ — lands on host = evil.example. Same string, two different hosts. That is why you must never validate a URL with one parser and fetch with another: parser disagreement is an allowlist-bypass/SSRF primitive — the validator approves the host it sees, the fetcher connects to the other one. [VERIFY this example against the current WHATWG URL Standard and one real library (e.g. new URL() in a browser vs a strict RFC-3986 parser) before relying on the exact split.]

When to use a URN vs a URL as your identifier

This is a real design decision the moment you store references to resources (in a database, an API payload, an event, a citation). The choice is identity coupled to location (URL) versus identity decoupled from location, resolved on demand (URN or an opaque persistent ID).

The trade-off. A URL is the cheapest possible identifier — one string, dereference it directly, no infrastructure. Its cost is link rot: identity is welded to location, so moving the resource invalidates every stored reference. A URN (or an opaque UUID/slug in your own namespace) buys location independence — you can move the bytes anywhere and only update the resolver mapping — but you pay for it with a resolver: extra infrastructure, an extra network hop of latency on every fetch, and a mapping table that must itself never be lost.

Choose a URN/persistent ID when the reference outlives the location and link rot is unacceptable (digital libraries, scientific citation, long-term media catalogs, cross-service entity IDs). Prefer a URL when you own the host, the resource is not expected to migrate, and the simplicity of direct dereferencing outweighs future flexibility. Many mature APIs split the difference: expose a stable opaque ID as the resource's identity and also return a self URL (HATEOAS-style) so clients get persistence and convenience at once.

Takeaways

• URI is the syntactic superset; URL and URN are two roles. A URL identifies and locates (How + Where); a URN only names (What).
• The distinction is mechanical: if the scheme carries a resolvable location (host/authority), it acts as a URL; if it is a name with no location, it is a URN and needs a resolver.
• Fragments are client-only; reserved characters must be percent-encoded per component; relative references need a base to mean anything.
• As a design choice, URN/opaque IDs trade a resolver hop for immunity to link rot; URLs trade future flexibility for zero-indirection simplicity.

Re-authored/Deepened for this guide. Sources: RFC 3986 (Uniform Resource Identifier: Generic Syntax, Berners-Lee et al.), RFC 8141 (Uniform Resource Names), the WHATWG URL Living Standard, and MDN Web Docs on URI/URL structure. Worked example and diagrams hand-authored.