1 Definition and scope

A URI, or Uniform Resource Identifier, is a standardized string used to identify a resource within a networked environment or another naming system. It provides a common framework for referring to web pages, files, services, and many other entities. A URI may identify something by where it can be found, by what it is called, or by both of these at once.

In technical use, the term is broader than a simple web address. It covers a family of identifiers that share a common syntax and are intended to be interpreted consistently across software systems. Because of this generality, URIs play a central role in many internet protocols, document formats, and application interfaces.

1.1 Meaning of "identifier"

An identifier is a string that distinguishes one resource from another. In the URI context, the identifier is not necessarily a label chosen for human convenience; rather, it is a machine-processable reference that software can parse and compare. The same resource may have more than one URI, and a URI may sometimes identify a concept rather than a directly retrievable object.

1.2 Resource concept

The word resource is used broadly. It can refer to a document, an image, a service endpoint, a person, a dataset, or even an abstract concept. The resource does not need to be a physical file. What matters is that the URI serves as a stable reference within a particular naming or access system.

1.3 URI versus URL and URN

A URL, or Uniform Resource Locator, identifies a resource by location and often describes how to retrieve it. A URN, or Uniform Resource Name, identifies a resource by name within a namespace and is intended to be persistent rather than tied to a particular location. URI is the umbrella term that includes both patterns and other related forms.

1.4 Role in internet standards

URIs are embedded in the architecture of the web and many related standards. They appear in links, redirects, APIs, metadata, and protocol messages. Formal specifications define how URIs are formed, interpreted, compared, and resolved, which allows different software systems to exchange references reliably.

2 History

The URI concept emerged from the need to name and locate resources on the early internet and World Wide Web. As networked information systems expanded, a uniform syntax became necessary so that browsers, servers, and other software could exchange references without ambiguity. The resulting standards developed over time through work in internet engineering bodies.

2.1 Early web addressing

Early web systems used simple location-based strings to point to documents and services. These addressing methods worked well enough for basic linking, but they were not designed as a general identification framework. As the web grew, a more formal approach was needed to support diverse resource types and interoperable software.

2.2 Standardization by IETF

The Internet Engineering Task Force played a central role in defining URI syntax and semantics. Standardization efforts established common rules for schemes, authority components, paths, queries, and fragments. These specifications gave developers a shared model for constructing and parsing identifiers across protocols.

URI-related standards have been refined repeatedly to improve clarity and interoperability. Earlier documents distinguished among URLs, URNs, and general URIs, while later specifications emphasized a unified model. Related standards also addressed relative references, international characters, and normalization practices as internet use broadened.

3 Syntax and structure

A URI is usually composed of several parts, each with a specific function. Not every URI contains every component, and the meaning of a component can vary by scheme. Nevertheless, the general structure helps software recognize and process identifiers consistently.

3.1 Scheme

The scheme indicates the general type of URI and often suggests how it should be interpreted. It appears at the beginning of the identifier, followed by a colon. Common schemes include those for web access, email, file references, and specialized application protocols.

3.1.1 Common schemes

Common examples include http, https, ftp, mailto, file, and tel. Each scheme is associated with its own rules and usage patterns. Some schemes are widely supported by browsers and operating systems, while others are used in specialized software or protocols.

3.1.2 Scheme-specific rules

Although URI syntax is standardized at a high level, each scheme may define additional requirements. For example, one scheme may use an authority and path, while another may encode all relevant information in a different way. These scheme-specific rules determine how the URI should be interpreted after parsing.

3.2 Authority

The authority component typically identifies the party or host responsible for a resource location. It commonly appears after two slashes and before the path. In many web URIs, the authority is the portion most closely associated with a network location.

3.2.1 User information

Some URIs can include user information before the host, such as a username or other credentials-like data. This part is limited in modern practice because it can create confusion or security risks. Many applications discourage its use or ignore it when displaying or processing a URI.

3.2.2 Host

The host names the network location associated with the resource. It is often a domain name, though it may also be an IP address or another host reference. The host helps routing software determine where requests should be sent.

3.2.3 Port

A port number can follow the host and indicate a specific communication endpoint on that host. If omitted, the scheme often implies a default port. Including a port is useful when a service runs on a nonstandard endpoint.

3.3 Path

The path identifies a resource within the hierarchical structure of a site or namespace. It usually consists of segments separated by slashes. The path may resemble a file system path, although it does not always correspond to an actual file hierarchy.

3.3.1 Hierarchical paths

Hierarchical paths organize resources into levels. This structure is convenient for websites and APIs because it allows related items to be grouped together. The appearance of directories and files in the path can be descriptive rather than literal.

3.3.2 Relative paths

Relative paths omit some leading components and are interpreted in relation to a base URI. They are widely used in documents, web pages, and configuration files. Relative references make it easier to reuse links when content is moved within a broader structure.

3.4 Query

The query component carries additional data after a question mark. It is often used to pass parameters to a web service or application. The exact meaning of the query depends on the scheme or application context.

3.4.1 Parameter encoding

Query parameters are commonly written as key-value pairs separated by ampersands. Because some characters have special meaning, values may need encoding before inclusion. Proper encoding helps preserve data accurately and avoid parsing errors.

3.4.2 Use in web applications

Web applications frequently use queries to filter results, specify search terms, or control view options. They are also used in form submissions and API requests. In practice, the query string can influence caching, routing, and server-side processing.

3.5 Fragment

The fragment appears after a hash symbol and identifies a secondary part of the resource. It is usually interpreted by the client rather than sent to the server. Fragments are common in web pages and document systems for linking to subparts.

3.5.1 In-document navigation

Fragments can point to headings, sections, or named locations within a document. When a browser follows such a URI, it may scroll to the referenced location. This makes fragments useful for direct navigation inside long pages.

3.5.2 Client-side interpretation

The server typically does not receive the fragment portion of a request. Instead, the client uses it after retrieval to determine how the resource should be presented or where attention should be focused. This behavior allows fragments to support local navigation and application-specific state.

4 Types of URI

URIs are often classified by their intended function. Some are primarily locators, some are names, and some serve as references that do not fit neatly into either category. The classification reflects the purpose of the identifier rather than a strict structural difference.

4.1 Uniform Resource Locator

A URL identifies a resource by where it is located and usually how to access it. It is the most familiar form of URI in everyday use. In practice, many people use URL and URI interchangeably when referring to web addresses.

4.1.1 Location-based identifiers

Location-based identifiers point to a network endpoint or a retrievable address. Their usefulness depends on the resource remaining available at that location. If the location changes, the identifier may no longer resolve as expected.

4.1.2 Examples of URLs

Typical examples include web page links, download links, and API endpoints. A browser can use these strings to request resources over HTTP or HTTPS. Other software may treat them as access instructions for file transfer or service interaction.

4.2 Uniform Resource Name

A URN is intended to provide a persistent name for a resource within a defined namespace. Unlike a URL, it is not meant to describe where the resource resides. This makes URNs useful when the goal is long-term identification rather than direct retrieval.

4.2.1 Persistent naming

Persistent naming helps preserve references even if a resource moves or is mirrored in multiple places. A URN can remain stable while access methods change. This stability is valuable in citation systems, catalogs, and archival contexts.

4.2.2 Namespace-based identification

URNs depend on namespaces that establish how names are assigned and interpreted. The namespace provides the rules that prevent collisions and preserve uniqueness. Different namespaces can serve libraries, standards bodies, or other organized collections.

4.3 Other URI forms

Not all URIs fit neatly into the URL-URN distinction. Some are relative references, while others are opaque and do not expose a hierarchical structure. These forms still participate in the broader URI framework.

4.3.1 Relative references

Relative references lack a full scheme or authority and depend on a base URI for interpretation. They are common in HTML, XML, and other structured documents. Their compact form makes documents easier to author and maintain.

4.3.2 Opaque URIs

Opaque URIs do not have a visible hierarchical structure that generic software should interpret component by component. Their internal format is scheme-defined and may be treated as a single unit. This allows schemes to encode information in specialized ways.

5 Resolution and referencing

URIs are frequently used in contexts where one reference must be resolved against another. Resolution converts a relative or partial reference into a complete one. This process is important for linking, browsing, and document processing.

5.1 Absolute and relative URIs

An absolute URI includes enough information to stand on its own. A relative URI omits some components and must be interpreted in relation to a base. Both forms are common, but they serve different purposes in software systems.

5.2 Base URI

A base URI supplies the context needed to resolve relative references. It may come from the document location, a metadata field, or an explicit declaration. When multiple base rules apply, the effective base determines how the final identifier is constructed.

5.3 URI resolution algorithms

Resolution algorithms describe how to combine a relative reference with a base URI. They account for path segments, dot segments, and inherited components. Standard algorithms help ensure that different implementations produce the same result.

5.4 Canonicalization and normalization

Canonicalization and normalization reduce variation among equivalent or nearly equivalent URIs. This can involve case handling, percent-encoding decisions, or path cleanup. Careful normalization is useful for comparison, caching, and duplicate detection.

6 Encoding and character rules

URI syntax uses a restricted character set so that identifiers can be transmitted consistently across systems. When a resource name contains characters outside the permitted set, encoding mechanisms are used. These rules are essential for international use and reliable parsing.

6.1 Percent-encoding

Percent-encoding represents a character by a percent sign followed by two hexadecimal digits. It is used when a character is reserved or not allowed in a particular component. This method preserves data while keeping the URI safely transmittable.

6.2 Reserved and unreserved characters

Reserved characters have special syntactic meaning and may separate components or alter interpretation. Unreserved characters may appear without encoding in most situations. Understanding the distinction helps prevent accidental misreading of a URI.

6.3 Internationalized resource identifiers

Internationalized resource identifiers extend URI use to characters beyond basic ASCII, often through encoding or mapping strategies. This allows names and addresses to reflect a wider range of languages and scripts. Such support is important for global usability.

6.3.1 Punycode and domain names

Domain names containing non-ASCII characters are commonly represented in an ASCII-compatible form for network handling. Punycode is one mechanism used to encode such names. This permits browsers and resolvers to process internationalized hostnames.

6.3.2 Non-ASCII path and query data

Non-ASCII content may also appear in paths and queries after encoding. Applications must decode and display it carefully to preserve meaning and avoid corruption. Correct handling improves compatibility across platforms and locales.

7 Usage in computing

URIs are used throughout computing as a general-purpose reference mechanism. They support linking, identification, protocol interaction, and resource discovery. Their flexibility has made them a standard building block in many software environments.

7.1 Web browsers

Browsers use URIs to navigate between pages, submit forms, open files, and trigger scheme-specific actions. The address bar accepts many URI forms, not only web URLs. Browsers also rely on URI parsing for tabs, bookmarks, history, and security decisions.

7.2 APIs and web services

APIs commonly expose endpoints identified by URIs. These references define where requests are sent and often encode operations through path and query structure. In service-oriented systems, consistent URI design improves discoverability and client integration.

7.3 File and network resource references

URIs can point to local files, shared resources, or other network-accessible objects. Operating systems, desktop applications, and development tools often use them to abstract over different access methods. This makes a single referencing model useful across platforms.

7.4 Hypertext and documentation systems

Hypertext systems depend on URIs to connect documents and sections of documents. Documentation formats use them for citations, cross-references, embedded media, and anchors. Their presence helps readers move quickly between related materials.

8 Security and interoperability

Because URIs are widely shared and automatically processed, small differences in syntax can have security and compatibility consequences. Misinterpretation may lead to broken links, misleading displays, or access to unintended resources. Good implementation practices are therefore important.

8.1 Spoofing and ambiguity

Two URIs may look similar while pointing to different targets, especially when unusual characters or encoding are involved. Attackers can exploit visual similarity or parser discrepancies to mislead users or software. Clear display rules and strict parsing help reduce these risks.

Incorrect percent-encoding, double encoding, or inconsistent decoding can alter meaning. Components may be interpreted differently by clients, servers, or intermediaries if they do not follow the same rules. Robust handling requires attention to the exact component in which data appears.

8.3 Comparison and equivalence

Comparing URIs is not always straightforward. Some differences are superficial, while others change the target or interpretation. Applications often need explicit comparison rules to decide whether two identifiers should be treated as the same.

8.4 Best practices for safe handling

Safe URI handling includes using standard parsers, validating inputs, avoiding ad hoc string manipulation, and displaying identifiers in a clear form. Applications should encode data at the appropriate stage and decode it only where intended. Careful implementation improves both security and interoperability.

9 Examples

URIs appear in many everyday and technical settings. The examples below illustrate how different schemes and structures are used for communication, reference, and application control.

9.1 Web addresses

A common example is an HTTP or HTTPS address pointing to a web page or service endpoint. Such a URI may include a scheme, host, path, and optional query or fragment. These are the forms most users encounter when browsing the web.

9.2 Mail and telephone schemes

Scheme types such as mailto and tel demonstrate that URIs are not limited to web pages. A mailto URI can open an email composer with a recipient address, while a tel URI can identify a telephone number for calling software. These forms show how URIs can trigger actions in client applications.

9.3 Custom schemes

Software can define custom schemes for specialized environments. A desktop application, game launcher, or enterprise system may register its own URI scheme to open specific content or functions. Custom schemes extend the model beyond the browser.

Several related identifiers and abstractions build on or intersect with the URI model. They serve similar linking or naming purposes but differ in syntax, scope, or intended use. Understanding these related terms helps place URIs in a wider technical context.

10.1 IRI

An IRI, or Internationalized Resource Identifier, is a broader form that allows a wider set of characters than a traditional URI. It is designed to be more readable in languages beyond ASCII. IRIs are often mapped to URI-compatible forms for transport and processing.

10.2 URI template

A URI template is a pattern with variable placeholders used to generate URIs. It is common in APIs and code that constructs links dynamically. Templates make it easier to create families of related identifiers from shared structure.

10.3 Namespace identifiers

Namespace identifiers define naming systems that organize identifiers within a controlled scope. They are used in URNs, XML, and other standards to prevent collisions. A namespace clarifies how names are assigned and interpreted.

10.4 Resource locators in other systems

Other systems use location-like identifiers similar in spirit to URIs, even when they follow different conventions. These may include database references, application-specific addresses, or protocol-defined locators. The URI model provides a widely adopted reference point for such systems.