URL, URI, and URN Differences

A URI, URL, and URN are closely related terms, but they answer different questions.

A URI is the broadest category. It is any string that identifies a resource. A URL is a URI that tells you where the resource is and usually how to reach it. A URN is a URI that gives the resource a stable name inside a namespace, without saying where a current copy lives.

The set relationship matters more than the acronyms. Every URL is a URI. Every URN is a URI. Not every URI is a URL, and not every URI is a URN.

A generic URI has this shape:

scheme:[//authority]path[?query][#fragment]

The pieces have distinct jobs:

• scheme names the protocol or naming system, such as https, ftp, mailto, or urn.
• authority usually carries host and optional port information.
• path points to a resource or namespace-specific value.
• query passes extra parameters.
• fragment points to a subsection inside the returned representation.

Take this string:

https://example.com/reports/2026.csv?download=1#summary

It is a URL because it gives a location and an access method. A client can resolve the host, open an HTTPS connection, request /reports/2026.csv, and then interpret download=1. Because every URL is also a URI, it is both.

Now compare that with a URN:

urn:isbn:9780141187761

This identifies a book edition in the ISBN namespace. It names the resource, but it does not tell a client which server to contact. Some external system might map that URN to a catalogue entry or a retailer page, but that resolution is not built into the string itself.

This is the practical difference between locating and naming. A URL is operational. A URN is persistent in intent. A URI only promises identification.

In day to day engineering, people often say “URL” for any web-looking string and “URI” in specifications and configuration. That loose usage is common, but it can hide real constraints. If a field accepts only https://..., call it a URL. If it may accept mailto:, urn:, or a custom scheme, URI is the more accurate word. OAuth uses the term redirect_uri for this historical reason, even though most real values are ordinary HTTPS URLs.

A few edge cases cause confusion. A fragment such as #summary is not sent to the origin server in an HTTP request. It is interpreted by the browser or client after retrieval. A query string such as ?download=1 is sent to the server and often changes how the application handles the request. Both are part of the URI syntax, but they have different operational effects.

The main tradeoff is precision versus convenience. “URL” is familiar and often good enough in conversation. “URI” is safer in standards work, API contracts, parsers, and validation logic, where the accepted schemes and resolution behaviour matter. “URN” is worth using when the point is stable naming rather than network access.

If you remember one rule, use this one: a URL tells you where, a URN tells you what name, and a URI is the umbrella term that covers both.