What is the difference between a URI, a URL, and a URN?
Categories:
URI, URL, and URN: Understanding Web Identifiers

Demystify the core concepts of URI, URL, and URN, their relationships, and how they are used to identify and locate resources on the internet.
In the realm of web technologies, terms like URI, URL, and URN are frequently encountered but often misunderstood or used interchangeably. While they are related, each term has a distinct meaning and purpose, as defined by RFC 3986. Understanding these differences is crucial for anyone working with web resources, from developers to network architects. This article will break down each concept, illustrate their relationships, and provide practical examples.
What is a URI (Uniform Resource Identifier)?
A URI, or Uniform Resource Identifier, is a generic term for any string of characters that identifies a resource. The primary purpose of a URI is to provide a simple and extensible means for identifying resources. These resources can be anything: a document, an image, a video, a service, or even a real-world object. URIs are defined by RFC 3986, which states that a URI can be either a locator (URL), a name (URN), or both.
Think of a URI as the overarching category. It answers the question: "What is this resource?" It doesn't necessarily tell you where to find it, just what it is. A URI is composed of a scheme, an authority (optional), a path, a query (optional), and a fragment (optional).
flowchart LR subgraph URI A[Scheme] --> B[Authority (Optional)] B --> C[Path] C --> D[Query (Optional)] D --> E[Fragment (Optional)] end URI --> F{Resource Identification}
Basic structure of a URI
What is a URL (Uniform Resource Locator)?
A URL, or Uniform Resource Locator, is a specific type of URI that not only identifies a resource but also provides a means of locating it by describing its primary access mechanism (e.g., its network location). URLs are the most common type of URI you encounter daily, such as web addresses. They specify the protocol to be used (e.g., http
, https
, ftp
), the domain name or IP address, and the path to the resource.
URLs answer the question: "Where is this resource and how can I get it?" All URLs are URIs, but not all URIs are URLs. For example, https://www.example.com/documents/report.pdf
is a URL because it tells you exactly where to find the report.pdf
file using the HTTPS protocol on the www.example.com
server.
https://www.example.com:8080/path/to/resource?query=value#fragment
Example of a URL with its components
What is a URN (Uniform Resource Name)?
A URN, or Uniform Resource Name, is another specific type of URI that identifies a resource by its name in a persistent, location-independent manner. Unlike URLs, URNs do not specify how to access the resource; they only provide a unique, global, and persistent name for it. The idea behind URNs is that a resource might move, but its name should remain the same.
URNs answer the question: "What is this resource called, regardless of where it is?" A classic example is the ISBN for a book: urn:isbn:0451450523
. This URN uniquely identifies a specific edition of a book, but it doesn't tell you where to buy it or which library has it. To find the resource, you would need a 'resolver' that can translate the URN into one or more URLs.
While the concept of URNs is powerful for persistent identification, their widespread adoption and practical implementation have been limited compared to URLs.
urn:isbn:0451450523
urn:ietf:rfc:2141
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
Examples of URNs for different types of resources
graph TD A[URI (Uniform Resource Identifier)] --> B[URL (Uniform Resource Locator)] A --> C[URN (Uniform Resource Name)] B -- "Identifies & Locates" --> D(Resource) C -- "Identifies Persistently" --> D(Resource)
Relationship between URI, URL, and URN
In summary, while all URLs and URNs are URIs, they serve different purposes. URLs are for locating resources, and URNs are for naming them persistently. The broader term URI encompasses both, providing a unified framework for identifying anything on the web or beyond. Understanding this distinction is fundamental for designing robust and future-proof web systems.