URLs & Web Fundamentals
What is a URI?
A URI, Uniform Resource Identifier, is a string of characters that identifies a resource. It is the broader category that encompasses both URLs: Uniform Resource Locators, and URNs, Uniform Resource Names, as specific subtypes. Every URL is a URI but not every URI is a URL, a URI only needs to identify a resource, while a URL specifically identifies a resource and provides the means to locate it.
The distinction between URI and URL is one of the most consistently confused concepts in web technology, the terms are used interchangeably in casual conversation, in technical documentation, in browser interfaces, and in most development contexts. Understanding the precise distinction requires understanding the URI taxonomy that the IETF defined in RFC 3986, the foundational specification for URI syntax.
URI: identifies a resource. The string https://example.com/page identifies a specific web page. The string urn:isbn:978-3-16-148410-0 identifies a specific book by its ISBN number. Both are URIs, both identify resources, but only the first is a URL because only the first also specifies how to locate the resource.
URL: a URI that provides location information, the means to access the resource. A URL includes enough information, a scheme, authority, and path, to actually retrieve the resource it identifies. All URLs are URIs.
URN: a URI that provides a persistent, location-independent name for a resource. A URN identifies what a resource is without specifying where it is or how to access it. urn:isbn:978-3-16-148410-0 identifies a specific book but does not tell you where to find a copy. All URNs are URIs.
The URI taxonomy
Understanding the URI taxonomy, the relationship between URIs, URLs, and URNs, clarifies the conceptual framework that underlies web addressing.
The URI as the parent category: the URI is the most general concept, any string that conforms to the URI syntax specification and identifies a resource. The URI specification defines the syntax rules, the structure of scheme, authority, path, query, and fragment, that all URIs follow regardless of whether they are URLs or URNs.
The URL as location-providing URI: a URL is a URI that includes enough information to locate the resource, to actually retrieve it from the network. The scheme component of a URL specifies the protocol, https, ftp, mailto: that tells the client how to access the resource. The authority component specifies the server or service hosting the resource. Together these components transform a simple identifier into a locator.
https://example.com/page: a URL. The https scheme tells the browser to use HTTPS. example.com tells it which server to connect to. /page tells it which resource to request. The URL is both identifier and locator.
The URN as persistent name URI: a URN is a URI that provides a persistent, globally unique name for a resource independent of its location. URNs use the urn: scheme followed by a namespace identifier and a namespace-specific string.
urn:isbn:978-3-16-148410-0: a URN identifying a specific book. urn:ietf:rfc:3986: a URN identifying the RFC 3986 specification. urn:uuid:6ba7b810-9dad-11d1-80b4-00c04fd430c8: a URN using a UUID as a globally unique identifier.
URNs are important in systems that need to identify resources independently of their location, particularly useful for distributed systems, archival systems, and contexts where resources may move between locations while maintaining persistent identities.
Why the URI/URL distinction matters
For most practical web development and redirect management contexts the URI/URL distinction is academic, web addresses are URLs and the term URL is universally understood and appropriate. However the distinction matters in several specific contexts.
Specification and standards documentation: HTTP specifications, HTML specifications, and other web standards use URI as the technically precise term for web addresses. RFC 3986, the URI specification, is the authoritative reference for URL syntax. Understanding that these specifications say URI when they mean what most people call URL prevents confusion when reading technical documentation.
API design: REST API design frequently uses URI as the term for resource identifiers, particularly when the same logical resource might be accessible through multiple protocols or locations. A REST API that exposes /users/123 as a resource identifier may describe this as a URI because the identifier is conceptually independent of the protocol used to access it.
XML and RDF: XML namespaces and RDF, Resource Description Framework, use URIs extensively as identifiers for concepts, relationships, and resources in semantic web and linked data contexts. The URI in these contexts may be a URL, an address that can be dereferenced to retrieve a definition, or a URN, a persistent identifier with no implied location.
Disambiguation in documentation: when writing technical documentation that must be precise about whether a string identifies or locates a resource using the correct term, URI for identifiers, URL for locators, communicates the intended meaning precisely.
Browser and developer tool interfaces: browser developer tools, network inspectors, and HTTP debugging tools frequently label the address field as URI rather than URL, using the technically correct broader term. Understanding that URI in these contexts refers to what is colloquially called a URL prevents confusion.
URI syntax
URI syntax is defined in RFC 3986, the same specification that defines URL syntax, since URLs are URIs. The syntax defines how URI components are structured and combined.
Generic URI syntax:
Scheme: the first component, followed by a colon. Identifies the protocol or naming system. https, http, ftp, mailto, urn, tel, data are all valid schemes. The scheme is required in an absolute URI, relative URI references may omit the scheme.
Hierarchical part: the main identifying component following the scheme colon. For network-accessible resources, URLs, the hierarchical part begins with // followed by the authority, domain and optional port, followed by the path. For non-network resources, URNs, the hierarchical part contains the namespace-specific identifier.
Path: the component within the hierarchical part that identifies the specific resource within the authority’s namespace. In a URL the path is the sequence of /-separated segments following the authority, /products/blue-widget. Path segments may be empty, consecutive slashes, though this is generally avoided in clean URLs.
Query: the optional component following ?. Contains additional parameters in key-value form, sort=price&colour=blue. The query component refines the resource identification within the authority and path.
Fragment: the optional component following #. Identifies a sub-resource or section within the primary resource, #specifications. Processed by the client rather than sent to the server.
URIs in redirect management context
In redirect management the URI/URL distinction rarely requires explicit acknowledgement, redirect rules operate on URLs, and URL is the appropriate term for all practical purposes. However URI concepts appear in specific redirect management contexts.
HTTP Location header: when a server returns a redirect response the Location header specifies the redirect destination. The HTTP specification defines the Location header value as a URI reference, technically acknowledging that it may be an absolute URL or a relative URI reference. In practice redirect destinations are almost always absolute URLs, including scheme and authority, to avoid ambiguity in how relative references are resolved.
Redirect rule pattern matching: redirect management platforms match incoming request URIs against configured source patterns. The URI being matched includes the path and query string, not the scheme or authority, which are determined by which server receives the request. Understanding that redirect rules match against the URI path and query components, rather than against the complete absolute URL, clarifies how pattern-based redirect rules work.
Canonical URI vs canonical URL: in SEO contexts canonical URL is the standard term but the underlying concept, the definitive identifier for a resource, is a canonical URI concept. The canonical URL specifies the exact absolute URL, including scheme and authority, that should be treated as the definitive identifier for a resource.
URI vs URL in practice
The practical guidance for when to use each term is straightforward, use URL in virtually all web development and SEO contexts, use URI when precision requires distinguishing between locating and identifying, or when following the terminology of a specification you are implementing.
Use URL for: web addresses in HTML, CSS, and JavaScript. Browser address bars. HTTP request targets. SEO and redirect management contexts. Any context where the address specifies a network-accessible resource. Conversations with non-specialists where URL is universally understood.
Use URI for: technical specifications and documentation that follow RFC 3986 terminology. API documentation where the same resource might be accessed through multiple protocols. Semantic web and linked data contexts using RDF and XML namespaces. Contexts where you need to distinguish between locating and naming resources. Developer tool interfaces and HTTP debugging contexts that use the technically precise term.
In redirect management specifically: the term URL is universally used and universally correct. Redirect rules map source URLs to destination URLs. 301 redirects specify a Location URL. Canonical tags point to canonical URLs. The term URI adds no practical precision in redirect management contexts beyond what URL already communicates, the distinction between locating and naming is not relevant when every redirect management resource is a network-accessible URL.
Common URI-related misconceptions
URI and URL mean the same thing: technically incorrect but practically harmless in most contexts. Every URL is a URI but not every URI is a URL. In web development and SEO contexts every resource being discussed is a URL, using URI and URL interchangeably in these contexts does not cause practical problems.
URIs must be unique globally: URIs should identify resources uniquely within their scheme’s namespace but global uniqueness across all schemes is not strictly required. Different URI schemes may use the same string to identify different things, https://example.com/page and ftp://example.com/page are both URIs but identify different resources accessed through different protocols.
All URIs are accessible on the web: URNs are URIs but are not necessarily web-accessible. urn:isbn:978-3-16-148410-0 identifies a book but you cannot type it into a browser and receive the book. URIs identify resources, URLs locate them, the URL is what makes a web resource accessible.
Fragment identifiers are part of the URI sent to the server: fragments, the #section part of a URL, are part of the URI as defined but are not included in HTTP requests to the server. The browser processes fragments locally, scrolling to the identified section, without involving the server. This means server-side redirect rules cannot access or match fragment identifiers.