URL vs URI vs URN: The Differences Explained

URL, URI, and URN are three of the most confused acronyms in web development. They are related but not interchangeable, and the relationship between them is the part most explanations get wrong. This guide defines each term precisely, shows the syntax, and explains why the modern web has quietly collapsed two of them into one.

The short answer

A URI (Uniform Resource Identifier) is the umbrella term: any string that identifies a resource. A URL (Uniform Resource Locator) is a URI that also tells you where the resource is and how to retrieve it. A URN (Uniform Resource Name) is a URI that names a resource permanently without saying where to find it.

In set terms, every URL is a URI and every URN is a URI, but not every URI is a URL. The classic teaching diagram shows URI as a large circle containing two smaller, mostly separate circles labeled URL and URN.

What a URI actually is

The authoritative definition lives in RFC 3986, which describes a URI as a compact sequence of characters that identifies an abstract or physical resource. The generic syntax has up to five components, and recognizing them is the single most useful skill here.

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

  https://www.example.com:443/path/page?id=42#section
  \___/   \_______________/\________/\____/ \_____/
 scheme       authority       path    query  fragment

The scheme (here https) names the rule set for interpreting the rest. The authority usually holds a host and optional port. The path identifies a resource within that authority. The query carries non-hierarchical parameters, and the fragment points to a secondary resource, such as an anchor within a page. A URI does not have to include all of these; mailto:dev@example.com and tel:+15551234567 are valid URIs with no authority at all. If you want to take a string apart and inspect each piece, a URL parser makes the boundaries explicit.

What makes something a URL

A URI becomes a URL when it specifies a means of locating the resource, typically through a network protocol. The presence of an actionable scheme such as http, https, ftp, or file plus an address is what gives a URL its "where and how." Put differently, a URL is a URI that you can dereference: hand it to a client and the client knows what to fetch and from where.

Examples that are URLs:

• https://thisdevtool.com/tools/json-formatter — fetch over HTTPS from a host
• ftp://files.example.org/archive.zip — retrieve over FTP
• file:///home/user/notes.txt — open from a local filesystem

Because URLs travel over the wire, certain characters in them must be percent-encoded so they survive transport without ambiguity. Spaces, non-ASCII text, and reserved delimiters all have encoding rules; our guide to URL encoding covers the edge cases, and the URL encoder handles the conversion for you.

What makes something a URN

A URN is a URI under the urn scheme that names a resource persistently and globally, independent of location. It answers "what is this" rather than "where is this." The format defined in RFC 8141 is:

  urn:<namespace-identifier>:<namespace-specific-string>

  urn:isbn:9780131103627          (a specific book)
  urn:ietf:rfc:3986               (an IETF RFC)
  urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

A URN such as urn:isbn:9780131103627 identifies a book no matter which library, store, or website hosts a copy. The name stays valid even after every individual copy moves or disappears. UUIDs are commonly expressed as URNs in the urn:uuid namespace; if you need stable identifiers like these, a UUID generator produces them, and our comparison of UUID, ULID, and CUID explains when each fits.

Crucially, a URN does not tell a browser where to download anything. Resolving a URN to a concrete location requires a separate resolution system, which is one reason URNs never became part of everyday web browsing.

Comparing them side by side

The table below summarizes the practical distinctions.

Why the modern web treats "URL" and "URI" as one

Here is the part that resolves most confusion. The WHATWG URL Standard, which is what browsers actually implement, deliberately uses the single term "URL" and treats the older URI/URN distinction as a source of needless confusion. In practice, the web platform, JavaScript's URL interface, and most developer tooling say "URL" for what RFC 3986 would call a URI.

So both views are correct in their own context. In formal IETF specifications, URI is the superset and URL and URN are subsets. In day-to-day web development and in the living browser standard, "URL" is the working term and you rarely encounter a true URN. You should know the formal hierarchy for interviews, RFCs, and library documentation, but you will not be wrong calling an everyday web address a URL.

Common pitfalls and how to avoid them

Calling every identifier a URL. A data: URI that embeds bytes inline, or a urn: string, is a URI but arguably not a locator in the traditional sense. When precision matters, say URI.

Assuming a URN can be opened in a browser. It cannot, on its own. URNs require a resolution service to map the name to an actual address; without one they are identifiers, not addresses.

Confusing the fragment with the resource. The part after # is processed by the client after retrieval and is never sent to the server in an HTTP request. Two URLs differing only by fragment fetch the identical resource.

Forgetting to encode. Unencoded spaces, &, ?, or non-ASCII characters in a path or query can break parsing or change meaning. Internationalized hostnames are handled separately through Punycode; if you work with non-ASCII domains, a Punycode converter shows the ASCII-compatible form a resolver actually uses. For everything inside the path and query, percent-encode first.

Frequently Asked Questions