Uniform Resource Identifier (URI): Generic Syntax
obsoletes
- rfc-1808 — Relative Uniform Resource Locators
- rfc-2396 — Uniform Resource Identifiers (URI): Generic Syntax
- rfc-2732 — Format for Literal IPv6 Addresses in URL's
updated by
updates
- rfc-1738 — Uniform Resource Locators (URL)
also
- std-66
Extracted elements (318)
A URI only provides identification; access to the resource is neither guaranteed nor implied. Operations on a resource (access, update, replace) are defined by the protocols and data formats that use URIs, not by the URI specification itself. This separation allows URIs to be used purely as names without any retrieval intent.
A URI provides identification only; access to the resource is neither guaranteed nor implied by the presence of a URI. Operations on the resource are defined by the protocol or data format in which the URI appears, not by this specification — separating identification from interaction.
A URI provides identification only; the presence of a URI does not imply that the resource is accessible or that access will be attempted. Operations on resources are defined by the protocols that use URIs, not by this specification, separating the concern of naming from the concern of access.
A URI provides only identification; access to the resource is neither guaranteed nor implied by the presence of a URI. Operations on a URI (access, update, replace) are defined by the protocols and data formats that use the URI, not by this specification.
Base URI establishment follows a precedence order (innermost highest): (1) base URI embedded in content, (2) base URI of the encapsulating entity, (3) URI used to retrieve the representation, (4) application-defined default. A sender of relative references is responsible for ensuring a well-defined base URI exists.
Fragment identifier semantics are defined by the media type of the retrieved representation, not by the URI scheme, making them orthogonal to scheme definition. This prevents information providers from denying reference authors the right to selectively refer to content within a resource.
Fragment identifiers are handled client-side by the user agent rather than by the server or scheme to prevent information providers from denying reference authors the right to refer selectively to parts of a resource. Fragment identifier semantics cannot be redefined by scheme specifications because fragment identification is orthogonal to scheme definition.
Fragment identifiers are intentionally processed client-side only and not sent to the origin server, preventing information providers from denying reference authors the right to selectively refer to portions of a resource. This also makes deploying new media types easier than defining new URI schemes, since fragment semantics are media-type-defined.
Fragment identifiers are processed solely by the user agent and never sent to the server. This design prevents resource providers from blocking selective referencing by clients and makes it easier to deploy new media types without defining new URI schemes.
Future specifications should use the general term "URI" rather than the more restrictive "URL" or "URN". The URL/URN distinction depends on persistence and naming authority practice, not on the scheme itself; any scheme's instances may have characteristics of both names and locators.
IPv6 literals are enclosed in square brackets ("[" and "]") to unambiguously distinguish them from the colon-delimited port in the authority component. Square brackets are the only place in URI syntax where these characters are allowed, and a version flag ("v" HEXDIG ".") is reserved for future IP literal formats.
The fragment identifier is handled client-side by design, preventing information providers from denying reference authors the right to selectively refer to information within a resource. This also allows new media types to be defined more easily than new URI schemes.
The fragment identifier is processed client-side only and not passed to origin servers. This design prevents resource providers from denying reference authors the right to selectively reference portions of a resource, and makes new media types easier to deploy than new schemes.
The fragment identifier is processed exclusively by the user agent and is stripped from the URI before any scheme-specific dereference. This design prevents resource providers from denying authors the right to refer selectively to portions of a resource, and makes fragment semantics orthogonal to scheme definitions.
The fragment identifier is processed exclusively client-side (by the user agent) and is stripped from the URI before any dereference operation. This design prevents information providers from controlling how reference authors selectively identify portions of a resource, and allows fragment semantics to be defined by media type rather than URI scheme.
The fragment identifier is processed solely by the user agent rather than passed to the server or handled by scheme-specific logic. This prevents resource providers from denying reference authors the right to refer to sub-parts of a resource, and makes new media type definitions easier to deploy than new URI schemes.
The fragment identifier is resolved entirely client-side and is not sent to the origin server. This design prevents information providers from denying reference authors the right to link selectively to portions of a resource, and keeps fragment semantics extensible via media type definitions without requiring new URI schemes.
The fragment identifier is separated from the rest of the URI before any dereference and is processed solely by the user agent, independent of the URI scheme. This prevents information providers from denying reference authors the right to selectively identify portions of a resource.
The fragment identifier is separated from the URI before any dereference and resolved solely by the user agent, independent of the URI scheme. This design prevents origin servers from denying reference authors the right to point to secondary resources within a primary resource.
The generic URI syntax is a superset of all valid URI schemes, enabling a scheme-independent parser to extract components without knowing scheme-specific requirements. This decouples the evolution of identification schemes from the evolution of protocols and implementations.
The generic URI syntax is defined as a superset of all valid URI scheme syntaxes. This allows scheme-independent parsing of any URI reference into its components without knowledge of scheme-specific semantics, decoupling the evolution of naming schemes from the protocols and formats that use URIs.
The hierarchical syntax using "/", "?", and "#" enables relative references, allowing document trees to be portable across schemes and server locations. New URI scheme designers should use generic hierarchical syntax unless there are compelling reasons to forbid relative referencing within that scheme.
The host ABNF is intentionally ambiguous between IPv4address and reg-name; the "first-match-wins" rule resolves this: if host matches IPv4address, treat it as an IPv4 literal. Square brackets are used exclusively to delimit IP literals to allow future IP literal formats via the IPvFuture rule.
The host ABNF rule is intentionally ambiguous between IPv4address and reg-name; disambiguation uses a "first-match-wins" rule: if the host matches IPv4address, it is treated as an IPv4 literal rather than a registered name. This avoids introducing a more complex grammar.
The limited character set of URIs (basic Latin letters, digits, and a few symbols) was chosen primarily to support global transcription across keyboards, media, and languages; transcribability was prioritized over using the most semantically meaningful characters.
The slash ("/"), question mark ("?"), and number sign ("#") delimit the hierarchical components of a URI, enabling scheme-independent relative references. Relative references allow document trees to be partially independent of their location and access scheme, supporting portability across "file", "http", and "ftp" simultaneously.
The terms URL and URN are considered subsets of URI; future specifications should prefer the general term "URI". Whether a given URI acts as a locator or a name depends on the persistence and care of the naming authority's identifier assignment, not on the scheme itself.
The URI character set is deliberately restricted to basic Latin letters, digits, and a few special characters to enable global transcription: a URI must be writable on paper, readable across keyboard layouts, and typeable on systems across languages and locales. Transcribability was considered more important than using the most semantically meaningful characters.
The URI character set is limited to basic Latin letters, digits, and a few special characters to support global transcription — the ability to write a URI on a napkin and type it into any computer. Transcribability was given higher priority than using the most semantically meaningful characters.
The URI character set is limited to the basic Latin alphabet, digits, and a few special characters to permit global transcription across diverse media (paper, keyboards, screens). The ability to transcribe a URI from one medium to another was prioritized over using the most meaningful but potentially untypeable characters.
The URI character set is restricted to basic Latin letters, digits, and a few special characters to support global transcription: URIs must be enterable on keyboards across languages and locales, and readable from non-digital media (e.g., napkin, billboard). Transcribability was prioritized over expressiveness.
The URI character set is restricted to US-ASCII letters, digits, and a few special characters to support global transcription: a URI written on a napkin must be re-enterable from any keyboard regardless of locale. Transcribability was explicitly considered more important than using the most semantically meaningful characters.
The URI syntax is hierarchically organized with components of decreasing significance from left to right, using "/", "?", and "#" as delimiters. This enables relative referencing, allowing document trees to be moved without changing internal references and to be served under multiple schemes simultaneously.
The URI syntax is intentionally a superset of all valid URI schemes, enabling a scheme-independent parser to extract major components without knowing scheme-specific requirements. This decouples the evolution of identification schemes from protocols and data formats.
The URI syntax is restricted to letters, digits, and a small set of special characters to support global transcription — the ability to write a URI on a napkin, read it, and type it on any keyboard. The ability to transcribe was considered more important than allowing the most semantically meaningful characters.
The URI syntax restricts characters to basic Latin letters, digits, and a few special characters to enable global transcription — i.e., a URI can be written on paper or a napkin and re-entered on any computer regardless of locale or keyboard. Transcribability was considered more important than meaningful components.
The URI syntax separates identification from interaction: a URI identifies a resource but neither guarantees nor implies that the resource is accessible. Operations on the resource (access, update, replace) are defined by the protocols that use URIs, not by the URI specification itself.
The URI syntax was designed with global transcription as a primary goal, restricting characters to the basic Latin alphabet, digits, and a few special characters so URIs can be written on paper and re-entered on any keyboard. The ability to transcribe a URI across media was considered more important than having maximally meaningful component names.
URI characters are restricted to a limited set (ASCII letters, digits, a few special characters) to support global transcription. The ability to copy a URI from one medium to another (e.g., from a napkin to a keyboard) was prioritized over allowing the most meaningful possible characters.
URI characters are restricted to basic Latin letters, digits, and a few special characters primarily to support global transcription: a URI must be writable on paper, typeable across keyboard layouts, and transferable between media. This requirement outweighed the goal of allowing maximally expressive component names.
URI identification is explicitly separated from interaction: a URI only identifies a resource; access is neither guaranteed nor implied by the presence of a URI. Operations on resources are defined by protocols that use URIs, not by the URI syntax itself.
URI identification is explicitly separated from resource interaction: a URI provides identification only, and access to the resource is neither guaranteed nor implied by the presence of a URI. Operations on the identified resource are defined by the protocols and data formats that use URIs, not by this specification.
URI identification is intentionally separated from interaction: the URI provides identification only; access to the resource is neither guaranteed nor implied. Operations on a URI are defined by the protocols that use it, not by the URI specification.
URI identification is intentionally separated from resource access: the URI provides identification only; the operations that may be performed on a resource are defined by the protocols that use URIs, not by the URI specification. A URI does not guarantee that a resource is accessible.
URI syntax is deliberately limited to the basic Latin alphabet, digits, and a few special characters to support global transcription—copying a URI between media such as paper and keyboard. The ability to transcribe a URI was considered more important than allowing the most semantically meaningful characters.
URI syntax is restricted to the basic Latin alphabet, digits, and a few special characters to support global transcription: the ability to write a URI on a napkin and later enter it on a computer. Transcribability was considered more important than maximally meaningful component characters.
URI syntax uses a limited character set (letters, digits, and a few special characters) to support global transcription—the ability to write a URI on a napkin and accurately enter it on any keyboard. The ability to transcribe an identifier from one medium to another was considered more important than allowing maximally meaningful or locale-specific component names.
URIs provide identification, not access; the presence of a URI neither guarantees nor implies resource accessibility. Operations on a resource are defined by the protocols and data formats that use URIs — URI 'resolution' (determining an access mechanism) and 'dereferencing' (performing an action) are conceptually distinct from identification.
A non-strict parser may ignore a scheme in a reference when it matches the base URI's scheme, treating the reference as relative. This is a loophole from RFC 1630 that should be avoided but is permitted for backward compatibility.
IPv6 and future IP literal addresses in the host subcomponent must be enclosed in square brackets—the only place square brackets are permitted in URI syntax. An application encountering an IPvFuture literal with an unknown version flag should return an "address mechanism not supported" error rather than attempt resolution.
Non-strict parsers may treat a URI reference as relative even when it contains a scheme component identical to the base URI's scheme, a behavior identified as a loophole in RFC 1630. Strict parsers must not apply this rule; its use should be avoided but is allowed for backward compatibility.
Older implementations may fail to separate a reference's query or fragment component from its path before merging with the base path and removing dot-segments. This causes incorrect resolution when query strings contain the substrings "/../" or "/./".
Some older, erroneous implementations fail to separate a reference's query and/or fragment components from the path component before merging with the base path and removing dot-segments. This causes interoperability failures when query or fragment strings contain "/./" or "/../".
Some older, erroneous implementations fail to separate the query and/or fragment components from the path before merging with a base path and removing dot-segments. This causes incorrect resolution when a query component contains "/../" or "/./", though such errors are rarely noticed in practice.
Some older implementations fail to separate a reference's query or fragment component from its path before merging with the base path during relative resolution, causing incorrect behavior when query strings contain "/../" or "/./". All parsers SHOULD be capable of resolving abnormal dot-segment examples consistently.
Some older implementations fail to separate the query and fragment components from the path before merging paths and removing dot-segments, causing failures when query strings contain "/../" or "/./". All parsers should handle the abnormal resolution examples in Section 5.4.2.
Some older parsers fail to separate a reference's query or fragment from the path before merging with the base path and removing dot-segments, causing failures when query strings contain "/./" or "/../". Compliant implementations must separate all components prior to path merge.
Some parsers allow a scheme name in a relative reference when it matches the base URI scheme (a loophole from RFC 1630). This usage should be avoided but is permitted for backward compatibility; a non-strict parser may choose to ignore such a matching scheme.
Some parsers allow a scheme name to appear in a relative reference if it matches the base URI scheme — a loophole from RFC 1630. Its use should be avoided but is allowed for backward compatibility. Strict parsers and non-strict parsers will resolve "http:g" against an http base URI differently.
Some parsers allow a scheme name to be present in a relative reference when it is identical to the base URI scheme — a loophole in prior specifications. Its use should be avoided but is permitted for backward compatibility with implementations following RFC 1630.
Some parsers allow the same scheme name to appear in a relative reference when it matches the base URI scheme, a loophole from RFC 1630. Its use should be avoided but is allowed for backward compatibility; strict parsers treat a reference with a defined scheme as absolute.
Some parsers allow the scheme name in a relative reference if it matches the base URI scheme (a loophole in RFC 1630). Its use should be avoided but is allowed for backward compatibility; strict parsers treat it as an absolute URI.
Some parsers treat a relative reference as scheme-relative when its scheme equals the base URI's scheme (e.g., "http:g" resolved against an http base). This loophole from RFC 1630 should be avoided in new implementations but is permitted for backward compatibility; strict mode MUST treat it as an absolute URI reference.
Some parsers treat a URI reference that carries the same scheme as the base URI as a relative reference (ignoring the scheme). This is a known loophole from RFC 1630; its use should be avoided but is permitted for backward compatibility with legacy implementations.
Suffix references (e.g., "www.example.com/path" used without a scheme) are commonly entered by users and heuristically resolved by clients, but have the same syntax as relative-path references and SHOULD be avoided in contexts where long-term references are expected, as heuristics change over time.
The "/" and "?" characters may represent data within query and fragment components, but some older erroneous implementations do not handle this correctly when such components are used as a base URI for relative reference resolution.
The IPv6address grammar in this document does not support IPv6 scoped addressing zone identifiers. The IP-literal syntax includes an IPvFuture rule to accommodate future IP literal address formats, with a version flag distinct from IP version numbers.
URI equivalence should be determined using a comparison ladder: simple string comparison (always required), syntax-based normalization (percent-encoding case, default port removal, dot-segment removal), scheme-based normalization, and protocol-based normalization (e.g., HTTP HEAD). Stronger normalization reduces false inequalities at the cost of additional processing.
A base URI for relative reference resolution MUST conform to the absolute-URI syntax rule and MUST be stripped of any fragment component before use. When a retrieval was the result of a redirect, the last URI used (the URI that resulted in actual retrieval) SHALL be considered the base URI.
A base URI must be established before parsing URI references that might be relative, must conform to the absolute-URI syntax rule (no fragment allowed), and must be in absolute form. If obtained from a URI reference, it must be converted to absolute form and stripped of any fragment component.
A base URI MUST conform to the absolute-URI syntax rule (scheme present, no fragment). If obtained from a URI reference, it must first be converted to absolute form and stripped of any fragment component.
A base URI used for relative reference resolution must conform to the absolute-URI syntax rule and must not include a fragment component. If derived from a URI reference, it must first be converted to absolute form and stripped of any fragment.
A path segment that contains a colon character (e.g., "this:that") MUST NOT be used as the first segment of a relative-path reference, as it would be mistaken for a scheme name; such a segment must be preceded by a dot-segment (e.g., "./this:that").
An implementation SHOULD accept uppercase letters as equivalent to lowercase in scheme names for robustness but SHOULD produce only lowercase scheme names. Scheme specifications must define their own syntax such that all conforming strings also match the absolute-URI grammar.
Applications SHOULD NOT render as clear text any data after the first colon in a userinfo subcomponent unless the data after the colon is empty. Applications MAY ignore or reject such data and SHOULD reject storage of such data in unencrypted form. The "user:password" format in userinfo is deprecated.
Applications SHOULD NOT render as cleartext any data after the first ":" in a userinfo subcomponent unless that data is an empty string. Applications MAY ignore or reject such data and SHOULD reject its storage in unencrypted form.
Data that conflicts with a reserved character's delimiter role must be percent-encoded before the URI is formed. If a reserved character is found in a URI component and no delimiting role is known for it, it must be interpreted as the data octet for that character's US-ASCII encoding.
Data that would conflict with a reserved character's delimiter role must be percent-encoded before the URI is formed. A reserved character found in a component with no known delimiting role must be interpreted as the data octet for that character's US-ASCII encoding.
For syntax-based normalization, percent-encoded octets in the ranges of unreserved characters (ALPHA, DIGIT, "-", ".", "_", "~") should not be created by URI producers and should be decoded by URI normalizers. Scheme and host components should be lowercased.
For URI comparison and normalization, implementations SHOULD perform syntax-based normalization including case normalization (scheme and host to lowercase), percent-encoding normalization (decode unreserved characters), and path segment normalization (remove dot-segments). URIs that differ only in these normalized forms are equivalent.
Fragment identifier semantics are independent of the URI scheme and cannot be redefined by scheme specifications. The fragment is separated from the rest of the URI prior to dereference and resolved solely by the user agent.
If a URI contains an authority component, the path must either be empty or begin with "/". If no authority is present, the path cannot begin with "//". A relative-path reference's first segment cannot contain ":".
Implementations MUST NOT percent-encode or decode the same string more than once, as decoding an already-decoded string may cause a data "%" octet to be misinterpreted as beginning a percent-encoding sequence.
Implementations SHOULD accept uppercase letters as equivalent to lowercase in scheme names for robustness, but SHOULD only produce lowercase scheme names for consistency.
IPv6 literal addresses are enclosed in square brackets (the only place square brackets appear in URI syntax): IP-literal = "[" ( IPv6address / IPvFuture ) "]". An unknown IPvFuture version flag SHOULD cause an "address mechanism not supported" error.
Non-ASCII registered names MUST be encoded as UTF-8 and each octet of the UTF-8 sequence percent-encoded for representation as URI characters. URI producing applications MUST NOT use percent-encoding in the host component unless it represents a UTF-8 character sequence.
Non-ASCII registered names must first be encoded according to UTF-8 and then each octet percent-encoded. URI producing applications must not use percent-encoding in host unless it represents a UTF-8 character sequence. For internationalized domain names intended for DNS resolution, the name must be transformed to IDNA encoding prior to lookup.
Non-ASCII registered names representing internationalized domain names intended for DNS resolution MUST be transformed to IDNA encoding prior to name lookup. URI producers MUST NOT use percent-encoding in the host subcomponent unless it represents a UTF-8 character sequence.
Only the dotted-decimal form of four decimal octets (0–255) is allowed for IPv4 addresses in URIs. URI producing applications MUST NOT use percent-encoding in host unless it is used to represent a UTF-8 character sequence. Non-ASCII registered names for DNS MUST be transformed to IDNA encoding prior to name lookup.
Percent-encoded octets corresponding to unreserved characters SHOULD NOT be created by URI producers and SHOULD be decoded to their unreserved character equivalents by URI normalizers.
Percent-encoded octets in the unreserved ranges (ALPHA, DIGIT, hyphen, period, underscore, tilde) should not be created by URI producers and should be decoded to their unreserved character equivalents by URI normalizers.
Scheme-based normalization allows applying scheme-specific default values: for example, omitting an empty port or default port (e.g., port 80 for http), normalizing an empty path to "/" when an authority is present, and treating an absent userinfo the same as an empty userinfo.
Scheme names are case-insensitive; an implementation SHOULD accept uppercase letters as equivalent to lowercase (e.g., "HTTP" as well as "http") for robustness but SHOULD produce only lowercase scheme names for consistency.
Scheme names are case-insensitive, but canonical form is lowercase. Documents specifying schemes MUST use lowercase letters. Implementations SHOULD accept uppercase letters as equivalent to lowercase for robustness but SHOULD only produce lowercase scheme names.
Scheme names are case-insensitive; implementations should accept uppercase letters as equivalent to lowercase but should only produce lowercase scheme names for consistency.
Scheme names begin with a letter followed by any mix of letters, digits, "+", "-", or ".". Although schemes are case-insensitive, the canonical form is lowercase; implementations should accept uppercase for robustness but must only produce lowercase scheme names.
Syntax-based normalization requires: percent-encoded unreserved characters should be decoded; empty port delimiter should be omitted; scheme and host are case-insensitive and should be lowercased. Normalizing percent-encoded octets that correspond to reserved characters changes URI semantics and MUST NOT be done.
Syntax-based normalization requires that percent-encoded octets in the unreserved character ranges (ALPHA, DIGIT, "-", ".", "_", "~") should be decoded, and scheme names and host names should be lowercased, to produce a canonical URI for comparison.
Syntax-based normalization SHOULD decode percent-encoded unreserved characters, normalize scheme and host to lowercase, and omit the port delimiter and value when the port is empty or equals the scheme default.
The remove_dot_segments algorithm must be applied after path extraction to eliminate "." and ".." complete path segments from the target URI path. More ".." segments than hierarchical levels in the base path are silently consumed rather than treated as errors.
The use of "user:password" format in the userinfo subcomponent is deprecated. Applications SHOULD NOT render as clear text any data after the first colon in userinfo unless it is the empty string, and SHOULD reject storage of such data in unencrypted form.
The "user:password" format in the userinfo field is deprecated. Applications should not render as clear text any data after the first ":" in userinfo unless it is empty, and should reject storage of such data in unencrypted form.
The "user:password" format in userinfo is deprecated. Applications SHOULD NOT render as clear text any data after the first ":" in a userinfo subcomponent and SHOULD reject storage of such data in unencrypted form.
URI normalization requires that percent-encoded octets for unreserved characters SHOULD be decoded, the default port SHOULD be omitted, and the scheme and host SHOULD be lowercased. URIs differing only in these normalized forms are equivalent.
URI normalizers should decode percent-encoded octets in the ranges of ALPHA, DIGIT, hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) to their corresponding unreserved characters, since such encodings are equivalent to their literal form.
URI producers and normalizers should decode percent-encoded octets in the unreserved character ranges (ALPHA, DIGIT, "-", ".", "_", "~") and should use uppercase hex digits for all percent-encodings that are retained.
URI producers and normalizers should omit the port component and its ":" delimiter if port is empty or if its value equals the scheme's default port value.
URI producers and normalizers SHOULD use uppercase hexadecimal digits for all percent-encodings and SHOULD NOT create percent-encoded octets for characters in the unreserved set (ALPHA, DIGIT, "-", ".", "_", "~"); URI normalizers should decode such encodings when encountered.
URI producers MUST NOT provide the IPvFuture version flag ("v" prefix) for existing IPv4 and IPv6 literal address forms. Applications encountering an IP-literal with an unknown version flag SHOULD return an error for "address mechanism not supported".
URI producing applications MUST NOT use percent-encoding in the host subcomponent unless representing a UTF-8 character sequence. Non-ASCII internationalized domain names intended for DNS MUST be transformed to IDNA encoding prior to name lookup.
URI producing applications SHOULD percent-encode data octets corresponding to reserved characters unless the URI scheme explicitly allows those characters as data. If a reserved character appears with no known delimiting role, it MUST be interpreted as the data octet for that character in US-ASCII.
URI scheme specifications MUST define their own syntax so that all strings matching their scheme-specific syntax will also match the absolute-URI grammar. Scheme specifications must not define fragment identifier syntax.
Use of the format "user:password" in the userinfo field is deprecated. Applications SHOULD NOT render as clear text any data after the first colon in a userinfo subcomponent unless the data after the colon is the empty string.
Use of the "user:password" format in the userinfo field is deprecated. Applications SHOULD NOT render as clear text any data after the first colon in userinfo unless the data after the colon is empty, and SHOULD reject storage of such data in unencrypted form.
Use of "user:password" format in the userinfo subcomponent is deprecated. Applications SHOULD NOT render as clear text any data after the first colon in userinfo unless that data is empty, and SHOULD reject storage of such data in unencrypted form.
Use of "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon in userinfo unless that data is the empty string, and should reject storage of such data in unencrypted form.
When a new URI scheme component represents Universal Character Set text, data SHOULD first be encoded as UTF-8 octets, and only those octets outside the unreserved set should be percent-encoded. This ensures non-ASCII characters are represented uniformly.
When a new URI scheme defines a component representing text from the Universal Character Set, the data should first be encoded as UTF-8 octets, then only those octets not in the unreserved set should be percent-encoded.
When a new URI scheme defines textual components from the Universal Character Set (UCS), data SHOULD first be encoded as UTF-8 octets, then only octets not corresponding to unreserved characters SHOULD be percent-encoded.
When a non-ASCII registered name represents an internationalized domain name intended for DNS resolution, the name MUST be transformed to IDNA encoding (RFC 3490) prior to name lookup. URI producers SHOULD provide these names in IDNA encoding rather than percent-encoding to maximize interoperability.
When a scheme-specific parser encounters a URI violating scheme-specific restrictions, it SHOULD flag the reference as an error rather than silently ignoring unused parts, to reduce equivalent URIs and detect potential misleading constructions.
When a URI contains an IP-literal starting with "v" (an IPvFuture version flag) that an application does not recognize, the application should return an error for "address mechanism not supported" rather than attempting to dereference it.
When a URI is dereferenced, components significant to the scheme-specific process MUST be parsed and separated before percent-encoded octets within those components are decoded, to prevent data from being mistaken for component delimiters. Unreserved-set octets may be decoded at any time.
When comparing URIs, syntax-based normalization requires that percent-encoded octets corresponding to unreserved characters be decoded, that scheme and host be lowercased, and that empty or default port numbers be normalized. Protocol-based normalization may use knowledge of scheme defaults (e.g., default port 80 for http) to further reduce equivalent forms.
When dereferencing a URI, components significant to scheme-specific processing MUST be parsed and separated before percent-encoded octets within those components can be safely decoded; premature decoding may cause delimiter confusion.
A relative reference has the form: relative-ref = relative-part [ "?" query ] [ "#" fragment ]. It can be a network-path reference ("//…"), absolute-path reference ("/…"), or relative-path reference; a first segment containing ":" must be preceded by "./".
A relative reference may be a network-path reference (begins with "//"), an absolute-path reference (begins with "/"), or a relative-path reference (no leading slash). A relative-path reference's first segment cannot contain a colon, as it would be mistaken for a scheme name; such segments must be preceded by "./".
A relative reference uses the hierarchical URI syntax to express a target relative to a base URI: relative-ref = relative-part [ "?" query ] [ "#" fragment ]. Types include network-path references ("//"), absolute-path references ("/"), and relative-path references (no leading slash).
A scheme name must begin with a letter and may be followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"): scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Scheme names are case-insensitive; canonical form is lowercase.
A URI consists of a hierarchical sequence of five components: scheme, authority, path, query, and fragment. The generic ABNF is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path are required; path may be empty.
A URI consists of five hierarchical components: scheme, authority, path, query, and fragment, expressed as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path are required; authority, query, and fragment are optional.
A URI has five hierarchical components: scheme, authority, path, query, and fragment, with the ABNF: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path are required (path may be empty); authority, query, and fragment are optional.
A URI is composed of five hierarchical components: scheme, authority, path, query, and fragment. ABNF: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path are required; path may be empty.
A URI-reference is either a URI or a relative-ref. A relative reference is identified when its prefix does not match a scheme followed by ":". Relative references may be network-path ("//"-prefixed), absolute-path ("/"-prefixed), or relative-path (no slash prefix).
A URI-reference is either an absolute URI or a relative-ref. A relative reference is resolved against a base URI using the algorithm in Section 5.2, which produces a target URI by conditionally inheriting scheme, authority, path, and query components from the base.
Base URI is established in order of precedence: (1) embedded in content, (2) from the encapsulating entity, (3) from the retrieval URI (the last URI after redirects), (4) application-defined default. A base URI must conform to the absolute-URI syntax rule.
Base URI is established with four levels of precedence (highest to lowest): (1) base URI embedded in content, (2) base URI of the encapsulating entity, (3) URI used to retrieve the representation, (4) application-defined default base URI.
Base URI precedence from highest to lowest: (1) base URI embedded in content, (2) base URI from the encapsulating entity, (3) retrieval URI (last URI after redirects), (4) application-defined default. The innermost (highest-precedence) defined base wins.
Base URI precedence (highest to lowest): (1) base URI embedded in content, (2) base URI of the encapsulating entity, (3) URI used to retrieve the representation, (4) application-defined default. A base URI must conform to the absolute-URI syntax rule.
Base URI precedence (highest to lowest): (1) embedded in content, (2) from the encapsulating entity, (3) the retrieval URI (last URI after redirects), (4) application-defined default. A sender of content containing relative references must ensure a base URI can be established.
Base URI precedence (innermost wins): (1) base URI embedded in content, (2) base URI from the encapsulating entity, (3) URI used to retrieve the entity, (4) application-defined default base URI. A sender of content with relative references is responsible for ensuring a base URI can be established.
Base URI precedence is established in four layers from highest to lowest: base URI embedded in content (5.1.1), base URI from the encapsulating entity such as a MIME container (5.1.2), the URI used to retrieve the representation after any redirects (5.1.3), and a default application-defined base URI (5.1.4).
Component recomposition reconstructs a URI string from parsed components by appending scheme+":", then "//"+authority if defined, then path, then "?"+query if defined, then "#"+fragment if defined. The distinction between an undefined component (delimiter absent) and an empty component (delimiter present, no content) is preserved.
Fragment identifier semantics are defined by the media type of the retrieved representation, are independent of the URI scheme, and cannot be redefined by scheme specifications. The fragment is separated from the URI before server-side dereferencing and resolved solely by the user agent.
IPv6 and future-format IP literals are enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". Square brackets are not allowed anywhere else in the URI syntax. IPvFuture format uses a version flag: "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ).
Reference resolution transforms a URI reference R against a base URI into a target URI T via a defined pseudocode algorithm: if R has a scheme, use R directly (removing dot-segments); otherwise inherit scheme and optionally authority and path from the base, merging and removing dot-segments as needed.
Reserved characters are divided into gen-delims (: / ? # [ ] @) and sub-delims (! $ & ' ( ) * + , ; =). Data that conflicts with a reserved character's delimiter role must be percent-encoded before the URI is formed.
Reserved characters are split into gen-delims (":", "/", "?", "#", "[", "]", "@") and sub-delims ("!", "$", "&", "'", "(", ")", "*", "+", ",", ";", "="). They serve as structural delimiters; URIs differing only in whether a reserved character is percent-encoded are not equivalent.
Reserved characters are split into gen-delims (":", "/", "?", "#", "[", "]", "@") used to delimit URI components, and sub-delims ("!", "$", "&", "'", "(", ")", "*", "+", ",", ";", "=") reserved for subcomponent delimiters. URIs differing by replacement of a reserved character with its percent-encoded equivalent are not equivalent.
Section 5.2 defines a normative pseudocode algorithm for resolving a relative reference against a base URI into a target URI, covering cases where the reference has a scheme, authority, empty path, absolute path, or relative path. Implementations may use other algorithms if results match.
The authority component has the form: authority = [ userinfo "@" ] host [ ":" port ]. It is introduced by "//" and terminated by the next "/", "?", "#", or end of URI. When present, the path must be empty or begin with "/".
The authority component has the form [ userinfo "@" ] host [ ":" port ], preceded by "//" and terminated by "/", "?", "#", or end of URI. All three subcomponents are optional.
The authority component has the structure: authority = [ userinfo "@" ] host [ ":" port ]. It is preceded by "//" and terminated by the next "/", "?", "#", or end of URI. When authority is present, the path must be empty or begin with "/".
The fragment component (fragment = *( pchar / "/" / "?")) begins after "#" and extends to end of URI. Fragment semantics are defined by the media type of the retrieved representation, not by the URI scheme; fragment identifier semantics cannot be redefined by schemes.
The fragment component (fragment = *( pchar / "/" / "?" )) is indicated by "#" and is separated from the URI before dereferencing. Fragment resolution is performed solely by the user agent; its semantics are defined by the media type of the retrieved representation, not by the URI scheme.
The fragment identifier (fragment = *( pchar / "/" / "?" )) is separated from the rest of the URI prior to dereference and is handled solely by the user agent. Fragment semantics are defined by the media type of the retrieved representation, not by the URI scheme.
The fragment identifier (indicated by "#") allows indirect identification of a secondary resource. Its semantics are defined by the media type of the primary resource, are independent of the URI scheme, and cannot be redefined by scheme specifications. The fragment is separated before dereference and processed solely by the user agent.
The fragment identifier is indicated by "#" and terminated by end of URI. Fragment semantics are defined by the media type of the retrieved representation, are independent of the URI scheme, and cannot be redefined by scheme specifications. The fragment is separated from the URI before dereferencing and is resolved solely by the user agent.
The fragment identifier is separated from the rest of the URI by "#" and is processed solely by the user agent; it is not sent to the origin server. Fragment semantics are defined by the media type of the retrieved representation, not by the URI scheme.
The generic URI syntax consists of five hierarchical components: scheme, authority, path, query, and fragment, expressed as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path components are required, though the path may be empty.
The host subcomponent is identified by an IP literal in square brackets (IPv6 or IPvFuture), an IPv4 address in dotted-decimal form, or a registered name. Host is case-insensitive. IPv6 literals use: IP-literal = "[" ( IPv6address / IPvFuture ) "]" — the only place square brackets are permitted in URI syntax.
The host subcomponent is IP-literal (IPv6 or IPvFuture address enclosed in square brackets), IPv4address in dotted-decimal notation, or reg-name. The first-match-wins algorithm disambiguates IPv4address from reg-name; host is case-insensitive.
The host subcomponent is one of: an IP-literal (IPv6 or IPvFuture address enclosed in "[" and "]"), an IPv4address in dotted-decimal form, or a reg-name. The first-match-wins rule disambiguates IPv4address from reg-name. IPv6 literals are the only context where square brackets are allowed in URI syntax.
The host subcomponent is one of: IP-literal (IPv6address or IPvFuture enclosed in "[" "]"), IPv4address in dotted-decimal, or reg-name. The "first-match-wins" rule disambiguates IPv4address from reg-name; host is case-insensitive.
The path component has five ABNF variants (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) to disambiguate context. If authority is present the path must be empty or begin with "/"; without authority the path cannot begin with "//".
The path component is always present (though it may be empty) and contains hierarchical identifying data. Five ABNF rules—path-abempty, path-absolute, path-noscheme, path-rootless, path-empty—cover all valid path forms. Dot-segments "." and ".." are resolved during reference resolution.
The path component is defined by five mutually exclusive ABNF rules (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) to disambiguate URI reference contexts. Dot-segments "." and ".." indicate relative hierarchy and are removed during resolution.
The path component uses five ABNF rules: path-abempty (begins with "/" or is empty), path-absolute (begins with "/" not "//"), path-noscheme (no colon in first segment), path-rootless, and path-empty. Dot-segments ("." and "..") represent relative position in the hierarchy and are removed during resolution.
The port subcomponent matches *DIGIT and follows host after a ":" delimiter. URI producers and normalizers should omit the ":" delimiter and port value if the port is empty or equals the scheme's default port.
The query component begins at the first "?" and ends at "#" or end of URI; it may contain pchar, "/", and "?". The fragment component begins at "#" and extends to end of URI; its semantics are defined by the resource's media type and processed solely by the user agent.
The query component is indicated by the first "?" character and terminated by "#" or end of URI: query = *( pchar / "/" / "?" ). The query carries non-hierarchical identifying data alongside the path. The characters "/" and "?" may represent data within the query.
The query component (query = *( pchar / "/" / "?")) begins after the first "?" and ends at "#" or end of URI. It carries non-hierarchical identifying data alongside the path.
The query component (query = *( pchar / "/" / "?" )) is indicated by "?" and terminated by "#" or end of URI. Query data is non-hierarchical and identifies a resource within the scope of the scheme and authority.
The reference resolution algorithm (Section 5.2.2) transforms reference R against base URI Base into target T by checking in order: whether R has a scheme (use R wholesale with dot-segment removal), whether R has an authority, whether R's path is empty, and whether R's path starts with "/".
The reference resolution algorithm transforms a URI reference R against a base URI into a target URI T by selectively inheriting scheme, authority, path, and query from either R or the base, then applying remove_dot_segments to the path.
The relative-reference resolution algorithm (Section 5.2.2) builds a target URI by preferring the reference's own scheme, authority, and path when defined, merging paths when the reference is path-only, and always copying the reference's fragment component.
The remove_dot_segments algorithm eliminates "." and ".." complete path segments using an input/output buffer loop. Excess ".." segments beyond the root are silently absorbed; they cannot change the authority component.
The remove_dot_segments algorithm eliminates "." and ".." path segments using an input/output buffer loop, consuming prefixes "../", "./", "/./", "/../" in priority order, discarding excess ".." segments beyond the root, and never allowing dot-segments to change the authority component.
The remove_dot_segments algorithm iterates over an input buffer: prefixes "../" and "./" are removed; "/./ " and "/." are replaced with "/"; "/../" and "/.." cause removal of the last output segment; remaining segments are moved to the output buffer.
The remove_dot_segments algorithm iteratively processes a path input buffer, removing "./" and "../" prefixes, replacing "/./" with "/", removing the last output segment when "/../" is encountered, and finally removing lone "." or ".." from the buffer. The result is the normalized path.
The remove_dot_segments algorithm iteratively processes "." and ".." path segments: "./" and "../" prefixes are stripped; "/./" is replaced by "/"; "/../" removes the last output segment; isolated "." or ".." are discarded.
The remove_dot_segments algorithm processes a path input buffer left-to-right: "../" and "./" prefixes are stripped; "/./" and "/." are replaced by "/"; "/../" and "/.." remove the last output segment; lone "." or ".." are removed; otherwise the first segment is moved to output.
The remove_dot_segments algorithm processes "." and ".." path segments using an input/output buffer loop: "/." or "/./" is replaced by "/"; "/../" or "/.." pops the last output segment; standalone "." or ".." is removed. Excess ".." segments beyond the root are silently absorbed.
The remove_dot_segments algorithm removes "." and ".." complete path segments from a resolved path using two buffers: input is processed left-to-right handling "../", "./", "/./", and "/../" prefixes, moving segments to the output buffer.
The remove_dot_segments algorithm (Section 5.2.4) processes "." and ".." path segments using an input buffer and output buffer, consuming the input left-to-right and adjusting the output accordingly. Extra ".." segments beyond the root do not change the authority component.
The remove_dot_segments algorithm uses two string buffers to iteratively process "." (current directory) and ".." (parent directory) path segments, absorbing excess ".." segments that would escape the path root rather than treating them as errors.
The scheme component begins with a letter followed by any combination of letters, digits, "+", "-", or ".": scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive; the canonical form is lowercase.
The scheme component matches ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ), is case-insensitive, and must begin with a letter. Canonical form is lowercase; implementations should accept uppercase for robustness but produce only lowercase.
The scheme component matches ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Scheme names are case-insensitive but the canonical form is lowercase; documents specifying schemes must use lowercase letters.
The userinfo subcomponent matches *( unreserved / pct-encoded / sub-delims / ":" ). The "user:password" format is deprecated; applications must not render clear-text data after the first colon and should reject storage of such data unencrypted.
The userinfo subcomponent may contain a username and optional scheme-specific authorization data, delimited from the host by "@". The "user:password" format is deprecated; data after the first ":" must not be rendered as cleartext.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") are allowed in any URI component without encoding. A URI differing from another only in the percent-encoding of an unreserved character is equivalent to it.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") carry no special delimiting meaning and need not be percent-encoded. A URI differing from another only by replacing an unreserved character with its percent-encoded equivalent identifies the same resource.
Unreserved characters — ALPHA, DIGIT, hyphen, period, underscore, and tilde — may appear in a URI without percent-encoding. URIs that differ only in the replacement of an unreserved character with its percent-encoded equivalent identify the same resource.
Unreserved characters—ALPHA, DIGIT, hyphen, period, underscore, tilde—may appear unencoded in any URI component. URIs differing only in replacement of an unreserved character with its percent-encoded equivalent identify the same resource.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") may appear in a URI without percent-encoding. URIs that differ only in the replacement of an unreserved character with its percent-encoded equivalent identify the same resource.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") may appear unencoded in any URI component. URIs differing only by replacement of an unreserved character with its percent-encoded equivalent are equivalent and identify the same resource.
URI component recomposition reconstructs a URI string from parsed components by conditionally prepending "scheme:", "//authority", appending path, then "?query" and "#fragment" if defined. An undefined component (separator absent) is distinct from an empty component (separator present but no value).
URI normalization and comparison proceeds through a ladder of equivalence tests: simple string comparison, syntax-based normalization (case normalization, percent-encoding normalization, path segment normalization), scheme-based normalization, and protocol-based normalization. URIs differing only in percent-encoding of unreserved characters are equivalent.
IANA maintains the registry of URI schemes; the process for registering new URI schemes is defined by BCP35. This specification establishes the generic syntax that all scheme-specific syntaxes must satisfy, and the URI scheme registry maps scheme names to their defining specifications.
The IANA URI scheme registry maps scheme names to their defining specifications. Registration of new URI schemes is governed by BCP 35. Each scheme specification must define its own syntax such that all scheme-specific URIs also match the absolute-URI grammar.
The URI scheme registry, maintained by IANA, maps scheme names to their specifications. Registration of new URI schemes is governed by BCP35. Each scheme specification must define syntax ensuring all conforming strings match the absolute-URI grammar.
The URI scheme registry maintains the mapping between scheme names and their specifications. Registration of new URI schemes is defined by BCP35; advice for scheme designers is in RFC 2718. This document does not itself create or update the registry but delegates all scheme-specific syntax to individual scheme specifications.
This document does not create new IANA registries but references the URI scheme registry maintained by IANA. Registration of new URI schemes is governed by BCP 35, and the scheme registry maps scheme names to their specifications.
URI schemes are registered in the URI scheme registry maintained by IANA. The process for registering new URI schemes is defined by BCP35; this document explicitly defers individual scheme syntax and semantics to separate scheme specifications.
Back-end systems that decode percent-encoded URIs before parsing component boundaries introduce path traversal and injection risks. Percent-encoded octets must not be decoded until the relevant component has been fully parsed and separated from its delimiters.
Back-end transcoding after percent-decoding can introduce unsafe characters. Systems that decode percent-encoded octets before passing data to back-end processes must ensure decoded data cannot be misinterpreted as control sequences or delimiters in the target system.
Back-end transcoding between character encodings (e.g., EBCDIC to UTF-8) applied to URI components can alter percent-encoded sequences in ways that bypass security filters. All security-relevant URI processing must occur after a single, consistent decode step.
Back-end transcoding of URI characters (e.g., when a gateway translates between character encodings) can introduce security vulnerabilities if percent-encoded reserved characters are decoded and re-encoded under a different encoding, potentially changing their interpretation as delimiters.
Back-end transcoding of URI components from one character encoding to another can expose vulnerabilities if percent-decoded octets are passed directly through the transcoding layer without re-encoding. Percent-encoded octets must be decoded only after components are fully parsed, and only before the reverse transcoding is applied.
Back-end transcoding of URI octets between character encodings can silently alter percent-encoded sequences and cause a URI to reference a different resource or bypass security checks. Percent-encoded octets must be decoded only after components are fully separated.
Back-end transcoding of URIs by intermediaries (gateways, proxies) that re-encode percent-encoded octets under a different character set can silently transform a URI into one identifying a different resource, potentially bypassing access controls.
Malicious parties may construct URIs with misleading userinfo that appears to be a trusted host name (e.g., "http://good.example.com@bad.example.com/"). Applications rendering URIs for user feedback should distinguish the userinfo visually from the host component.
Malicious URIs can be constructed to mislead users about the resource being accessed, for example by embedding misleading userinfo that resembles a trusted domain name (e.g., "http://www.trusted.example.com@evil.example.com/"). Applications rendering URIs for user feedback should display userinfo distinctly.
Malicious URIs can be constructed using percent-encoding to obscure the true target, or by using relative paths that escape expected boundaries. Applications should display decoded URIs to users but must process encoded forms for access control decisions.
Malicious URIs may be crafted to mislead users, for example by embedding userinfo that visually resembles a trusted domain name (e.g., 'http://trusted.example.com@attacker.example/'). Applications should render userinfo distinctly and scheme-specific parsers should flag constraint violations as errors rather than silently ignoring unused parts.
Maliciously constructed URIs can contain misleading userinfo crafted to look like a trusted domain name (e.g., "http://trusted.example.com@evil.example.net/"). Applications rendering URIs for user feedback should visually distinguish the userinfo subcomponent from the host.
Maliciously constructed URIs can exploit alternate percent-encodings or unexpected path traversal to bypass access controls. Applications enforcing security checks on URI components must fully parse, decode, and normalize URIs before comparison, as subtle encoding differences can disguise the true target.
Maliciously constructed URIs can mislead users about the nature of the referenced resource, for example by embedding a trusted-looking string in a component that is ignored by the scheme-specific resolver. User agents should render the userinfo subcomponent visually distinct from the host to expose such deception.
Maliciously constructed URIs can use percent-encoding, uncommon syntax, or lookalike characters to obscure the true nature of a URI from both users and automated security checks. Implementations should not blindly decode URIs before applying security policies, and scheme-specific parsers should flag references that violate scheme restrictions rather than silently ignoring unused parts.
Maliciously constructed URIs exploit percent-encoding to mislead users or bypass access controls; attackers may encode characters to avoid pattern-matching filters or to construct a URI that appears to point to a trusted host but does not. Applications must normalize before comparison.
Maliciously constructed URIs may contain misleading components such as userinfo crafted to appear like a trusted authority (e.g., "http://trusted.example.com@attacker.example.com/"). Applications rendering URIs for user feedback should distinguish userinfo visually from the host to counter such semantic attacks.
Maliciously constructed URIs may mislead users or exploit parsing inconsistencies. When a URI violates scheme-specific restrictions, the resolution process should flag the reference as an error rather than silently ignoring unused parts, to reduce equivalent URIs and help detect abuse of the generic syntax.
Maliciously constructed URIs may use percent-encoding, dot-segments, or scheme-specific syntax to bypass security checks in gateways or parsers. Software that validates URIs must normalize and fully parse URIs before making access-control decisions, applying the same transformation as the eventual dereference agent.
Maliciously constructed URIs may use percent-encoding, non-standard IP address formats, or unusual syntax to confuse back-end processing or bypass access controls. When a scheme-specific resolution process encounters a URI violating scheme restrictions, it should flag an error rather than silently ignore unused components.
Maliciously crafted userinfo subcomponents can be made to visually resemble trusted domain names (e.g., "http://trusted.example@evil.example/"). Applications should visually distinguish userinfo from the host; scheme-specific parsers should flag such URIs as errors.
Non-standard or rare IP address formats (e.g., octal, hex, mixed dotted notation) may be interpreted by some platforms but are not allowed by this grammar. An attacker can use such forms to bypass access controls or mislead users; only standard dotted-decimal IPv4 and bracket-enclosed IPv6 are valid.
Rare IP address formats — dotted-octal, dotted-hex, and single-number decimal — may be accepted by some platforms but are not valid URI syntax; only dotted-decimal IPv4 (four decimal octets) is permitted. Applications that silently normalize such forms may allow bypassing access controls based on URI comparison.
Rare IP address formats (octal, hexadecimal, fewer than four dotted-decimal octets) are accepted by some platforms but are outside the URI grammar. Implementations should reject them to prevent spoofing of IP addresses.
Rare IP address formats (octal notation, hexadecimal, or fewer than four dotted-decimal octets) may be accepted by some host platforms but are not valid URI syntax. An implementation accepting such formats could be tricked into connecting to an unexpected host.
Rare IP address formats — such as dotted notation with fewer than four parts, hexadecimal, or octal octets — may be accepted by some platforms but are not allowed by the URI grammar. Implementations accepting such forms risk being deceived about the actual network address being accessed.
Semantic attacks craft a URI whose userinfo subcomponent resembles a trusted host name (e.g., "http://trusted.example.com@evil.example.net/") to mislead users. Applications rendering URIs for user feedback SHOULD visually distinguish the userinfo subcomponent from the host.
Semantic attacks craft the userinfo subcomponent to mimic a trusted hostname, e.g., "http://trusted.example.com@evil.example.com/". Browsers and clients must distinguish userinfo from the host component; scheme-specific resolvers should flag references violating scheme syntax as errors rather than silently ignoring them.
Semantic attacks craft URIs (e.g., "http://trusted.example.com@hostile.example.com/") that visually appear to identify a trusted resource but actually identify a hostile one. Applications should render the userinfo portion distinctly and warn users.
Semantic attacks exploit the gap between a URI's visual appearance and its actual meaning; for example, using look-alike characters or misleading path structures to cause a user to believe they are accessing a trusted resource. URI scheme resolution processes should flag references that violate scheme-specific restrictions rather than silently ignoring unused parts.
Semantic attacks exploit the rendering of URIs to make a malicious URI appear to identify a trusted resource, for example by crafting a userinfo subcomponent that resembles a trusted domain name. Applications SHOULD render userinfo distinctly from the host to help users detect such deception.
Semantic attacks exploit the rendering of userinfo or misleading subdomains to make a URI appear to identify a trusted resource when it does not (e.g., "http://trusted.example.com@evil.example.com/"). Applications should render userinfo in a visually distinct way to aid user recognition.
Semantic attacks exploit the userinfo subcomponent to craft URIs that visually appear to identify a trusted authority but actually identify a different one — for example, 'http://trusted.example.com@evil.example.com/'. Applications rendering URIs for user feedback should distinguish the userinfo portion from the host.
Semantic attacks exploit the visual difference between what a URI appears to identify and what it actually denotes — for example, userinfo crafted to resemble a trusted domain name, or IDN homograph attacks. Applications rendering URIs for user feedback should visually distinguish the userinfo subcomponent from the host.
Semantic attacks exploit visual similarity between different URIs to mislead users. A userinfo subcomponent can be crafted to look like a trusted domain name (e.g., "http://trusted.example.com@evil.example.com/"). Applications should render userinfo distinctly from the host, and scheme-specific resolution should flag violations rather than silently ignoring unused parts.
Semantic attacks exploit visual similarity of IRIs and URIs to deceive users into trusting a hostile resource (e.g., internationalised characters that resemble ASCII). When a scheme-specific restriction is violated, the resolver should flag it as an error rather than silently ignoring unused parts.
Semantic attacks exploit visually similar characters or structures to construct a URI that appears to identify a trusted resource but actually identifies a malicious one. Scheme-specific resolution processes should flag violations as errors rather than silently ignoring unused parts.
Semantic (visual spoofing) attacks craft the userinfo or path subcomponents of a URI to resemble a trusted domain name when displayed. Applications rendering URIs for users should distinguish the userinfo subcomponent visually, and scheme-specific resolution should flag URIs that violate scheme syntax rather than silently ignoring unused parts.
Sensitive information (e.g., access credentials, session tokens) should not be embedded in URIs, as URIs may appear in server logs, Referer headers, browser history, or other accessible locations. Use of 'user:password' in userinfo is explicitly deprecated for this reason.
Sensitive information — including passwords, session tokens, and personal data — should not be placed in the URI, as URIs may be stored in browser history, server logs, referrer headers, and other locations not under the user's control.
Sensitive information such as passwords embedded in a URI should be avoided; if present, applications must not render it in clear text. Back-end transcoding of percent-encoded octets can expose data or alter interpretation if decoding occurs before scheme-specific parsing separates components.
Sensitive information such as passwords embedded in the userinfo component is a security risk. URIs containing authentication credentials in cleartext should not be stored or transmitted without additional protection; back-end transcoding between character encodings can inadvertently expose or corrupt data.
Sensitive information such as passwords in the userinfo component may be inadvertently exposed in log files, referrer headers, or browser history. The use of the "user:password" format in URIs has proven to be a security risk and is deprecated.
Sensitive information such as passwords in userinfo or credentials in query components should not be included in URIs, as such data may be stored in logs, referrer headers, or browser history. The passing of authentication information in clear text has proven to be a security risk in virtually every case it has been used.
Sensitive information such as passwords must not be included in URIs, as URIs are frequently logged, cached, and transmitted in headers. The "user:password" userinfo format is deprecated precisely because passing authentication in clear text has proven a security risk.
Sensitive information such as passwords or personal data should not be included in a URI, as URIs are often displayed, bookmarked, logged, or transmitted in the clear. The deprecated userinfo "user:password" format in particular exposes credentials in every context where the URI appears.
Sensitive information such as passwords, session tokens, or personal data should not be included in a URI, as URIs are frequently transmitted in the clear and logged by servers, proxies, and browser history. The userinfo "user:password" format is specifically deprecated.
Sensitive information such as passwords SHOULD NOT be embedded in URIs, as URIs appear in server logs, Referer headers, and browser history in plaintext. The deprecated userinfo password field is a primary vector for accidental credential exposure.
Some platforms accept non-decimal octet notations for IPv4 addresses (octal, hexadecimal). A URI constructed with such a form may be used to bypass access controls or security checks that compare the host string textually. Only dotted-decimal notation of four decimal octets is allowed by the grammar.
Some platforms accept non-standard IP address formats such as octal or hexadecimal dotted notation, which this grammar disallows (only standard dotted-decimal IPv4 is permitted). Implementations that pass host components to OS APIs without strict validation may be vulnerable to access-control bypasses when those APIs accept non-standard formats.
Some platforms accept non-standard IP address forms (octal notation, hexadecimal, fewer than four dotted octets) that resolve to valid IPv4 addresses but are not recognized as IP literals by naive parsers. These can be used to bypass access controls; parsers should reject non-dotted-decimal IPv4 forms.
Some platforms accept rare IP address formats (octal, hexadecimal, fewer than four dotted octets) not allowed by the URI grammar. User agents resolving host names must reject such forms to prevent attackers from bypassing access controls via alternate address representations.
Some platforms interpret non-standard dotted IP address formats (e.g., octal or hexadecimal octets) that are not valid per this grammar, allowing attackers to bypass access controls. Only standard dotted-decimal IPv4 notation is permitted by this specification.
Some platforms interpret non-standard IP address formats (octal, hexadecimal, fewer than four dotted-decimal parts) that differ from the RFC 3986 grammar. An application may be misled into connecting to a different host than expected if it fails to reject these forms.
Some platforms interpret non-standard IP address notations (octal, hexadecimal, fewer than four octets) that appear to differ from well-known addresses but resolve to them. Only dotted-decimal quad notation is allowed by this grammar; implementations should be alert to non-standard forms that may bypass address-based access controls.
URIs can be constructed maliciously to look like a trusted resource while actually directing the user elsewhere. Scheme-specific parsers should flag scheme-constraint violations as errors rather than ignoring unused parts, to detect potential misleading URIs.
Use of the "user:password" format in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon within a userinfo subcomponent and should reject storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in nearly every case.
Relative reference resolution (Section 5.2.2) transforms a reference R against base URI B into target URI T: if R has a scheme, use R entirely; else if R has an authority, use R's authority and apply remove_dot_segments to R's path; else if R's path is empty, inherit base path (and optionally base query); else merge paths and remove dot segments. The fragment always comes from R.
The reference resolution algorithm (Section 5.2.2) transforms reference R against base Base into target T: if R has a defined scheme, use R's components; else if R has authority, use R's authority and path; else merge R's path with Base's path; in all cases apply remove_dot_segments to the resolved path.
The reference resolution algorithm transforms a URI reference R against a base URI Base into target URI T. If R has a scheme, T takes R's components directly (with dot-segments removed). If R lacks a scheme but has an authority, T takes R's authority and path. Otherwise, T inherits base components progressively: authority, then path (merged with base path and dot-segments removed), then query, always appending R's fragment.
The remove_dot_segments algorithm processes a path using input/output buffers: leading "../" or "./" are stripped; "/./" is replaced with "/"; "/../" removes the last output segment; lone "." or ".." are removed; otherwise the first segment is moved to output. This removes all dot-segments before forming the target URI.
The remove_dot_segments algorithm processes two buffers: (A) strip leading "../" or "./"; (B) replace "/./" or "/. (end)" with "/"; (C) replace "/../" or "/.. (end)" with "/" and remove last output segment; (D) remove isolated "." or ".."; (E) otherwise move the first path segment to the output. This removes invalid or extraneous dot-segments before forming the target URI.
A percent-encoded octet is encoded as a character triplet: the percent character "%" followed by two hexadecimal digits representing the octet's numeric value (e.g., "%20" for SP). Uppercase hex digits A-F are equivalent to lowercase a-f.
A percent-encoded octet is represented as a character triplet: pct-encoded = "%" HEXDIG HEXDIG. The uppercase hexadecimal digits A–F are equivalent to lowercase a–f, and URIs differing only in the case of hex digits in percent-encoded octets are equivalent.
A scheme name is defined as: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive but the canonical form is lowercase; documents that specify schemes must use lowercase letters.
A URI scheme name must begin with a letter and be followed by any combination of letters, digits, plus (+), period (.), or hyphen (-). ABNF: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). The canonical form is lowercase.
An IP literal address (IPv6 or future versions) in a URI host is encapsulated within square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". This is the only place where square brackets are allowed in the URI syntax. The full IPv6address ABNF with eight 16-bit hex pieces and elision via "::" is specified.
IPv4 addresses in URIs must use strictly dotted-decimal notation (dec-octet "." dec-octet "." dec-octet "." dec-octet), where each octet is 0–255. Other dotted forms such as octal or hex are not permitted by the grammar.
IPv4 addresses must use strict dotted-decimal notation with four decimal octets in the range 0–255 (dec-octet). IPv6 addresses consist of eight 16-bit hex pieces separated by colons, optionally with a "::" elision for consecutive zeros, enclosed in square brackets.
IPv6 addresses in URI host literals are enclosed in square brackets without a version flag, encoding eight 16-bit pieces in case-insensitive hex separated by colons, with optional "::" elision for consecutive zero groups and optional IPv4 representation for the least-significant 32 bits.
IPv6 addresses in URIs are enclosed in square brackets without a version flag. IPv6 syntax allows eliding consecutive zero-valued 16-bit pieces as "::" and optionally representing the least-significant 32 bits in IPv4 dotted-decimal form.
IPv6 addresses in URIs must be enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". Square brackets are permitted nowhere else in URI syntax. IPvFuture reserves a version-flagged extension point: "v" 1*HEXDIG "." 1*(unreserved / sub-delims / ":").
IPv6 and future IP literal addresses in URIs are enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". IPvFuture uses a version flag "v" followed by hex digits and a dot; this bracketed form is the only place square brackets are permitted in URI syntax.
IPv6 literals are enclosed in square brackets and encoded as eight colon-separated 16-bit hex pieces; consecutive zero groups may be elided with "::". IPv4 address in dotted-decimal notation (four dec-octets 0–255 separated by ".") is the only allowed dotted form.
IPv6 literals are enclosed in square brackets: IP-literal = "[" ( IPv6address / IPvFuture ) "]". IPvFuture uses a version flag: IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ). This is the only place square brackets are allowed in URI syntax.
Percent-encoding encodes a data octet as a character triplet: the percent character "%" followed by two uppercase hexadecimal digits (pct-encoded = "%" HEXDIG HEXDIG). Uppercase and lowercase hex digits are equivalent, but producers SHOULD use uppercase.
Percent-encoding represents a data octet as a character triplet: "%" followed by two hexadecimal digits (pct-encoded = "%" HEXDIG HEXDIG). Uppercase and lowercase hex digits are equivalent; producers SHOULD use uppercase for all percent-encodings.
Percent-encoding represents a data octet as the character triplet pct-encoded = "%" HEXDIG HEXDIG, where the two hex digits encode the octet's numeric value. Uppercase and lowercase hex digits are equivalent, but producers SHOULD use uppercase for consistency.
Reserved characters are divided into gen-delims (":", "/", "?", "#", "[", "]", "@") and sub-delims ("!", "$", "&", "'", "(", ")", "*", "+", ",", ";", "="), delimiting URI components and subcomponents.
Reserved characters are split into gen-delims (: / ? # [ ] @) and sub-delims (! $ & ' ( ) * + , ; =). URIs differing only in whether a reserved character appears literal or percent-encoded are not equivalent and will be interpreted differently.
Scheme names conform to: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive; the canonical form is lowercase, and scheme specifications must define their scheme names using lowercase letters.
The authority component has the form: authority = [ userinfo "@" ] host [ ":" port ]. It is preceded by "//" and terminated by the next "/", "?", "#", or end of URI.
The authority component has the form [userinfo "@"] host [":" port]. IPv6 and future IP literals are enclosed in square brackets (IP-literal = "[" (IPv6address / IPvFuture) "]"), the only place square brackets are allowed in URI syntax.
The authority component has the structure: authority = [ userinfo "@" ] host [ ":" port ], preceded by "//" and terminated by the next "/", "?", "#", or end of URI. The userinfo subcomponent uses the format *( unreserved / pct-encoded / sub-delims / ":" ).
The authority component is: authority = [ userinfo "@" ] host [ ":" port ], preceded by "//" and terminated by the next "/", "?", "#", or end of URI. The host subcomponent may be an IP-literal, IPv4address, or reg-name and is case-insensitive.
The authority subcomponent has the structure [ userinfo "@" ] host [ ":" port ]. It is preceded by "//" and terminated by the next "/", "?", "#", or end of URI. The port delimiter ":" should be omitted when the port is empty.
The fragment identifier is indicated by "#" and terminated by end of URI. ABNF: fragment = *( pchar / "/" / "?" ). Fragment semantics are defined by the media type of the primary resource, not by the URI scheme.
The generic URI structure is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part may begin with "//" authority followed by a path, or may be a path alone. Scheme and path are always present (path may be empty); authority, query, and fragment are optional.
The generic URI syntax consists of five hierarchical components: scheme, authority, path, query, and fragment. The ABNF is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]. The scheme and path are required; path may be empty.
The generic URI syntax is defined as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part covers authority+path or path-only forms. Scheme and path components are required, though the path may be empty.
The generic URI syntax is: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part is "//" authority path-abempty, path-absolute, path-rootless, or path-empty. Scheme and path are always present; authority, query, and fragment are optional.
The host subcomponent is: host = IP-literal / IPv4address / reg-name. IPv6 and future IP literal addresses are enclosed in square brackets (IP-literal = "[" ( IPv6address / IPvFuture ) "]"), the only place square brackets are allowed in URI syntax.
The host subcomponent is one of: IP-literal (IPv6address or IPvFuture enclosed in "[" and "]"), IPv4address (dotted-decimal, four octets 0-255), or reg-name (sequence of unreserved / pct-encoded / sub-delims characters). The first-match-wins rule disambiguates IPv4address from reg-name.
The host subcomponent may be an IP-literal (IPv6 or IPvFuture enclosed in square brackets), an IPv4address in dotted-decimal form, or a reg-name. ABNF: host = IP-literal / IPv4address / reg-name. The host is case-insensitive.
The path component has five ABNF variants (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) disambiguated by context. The dot-segments "." and ".." are defined for relative traversal and removed during resolution via the remove_dot_segments algorithm.
The path component is defined by five ABNF rules (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) covering the valid combinations depending on whether authority is present and whether the path is relative. The dot-segments "." and ".." express relative position in the hierarchy.
The path component is defined by five mutually exclusive rules: path-abempty (begins with "/" or empty), path-absolute (begins with "/" but not "//"), path-noscheme (no leading colon), path-rootless, and path-empty. Dot-segments "." and ".." are removed during resolution.
The path is defined by five mutually exclusive ABNF rules (path-abempty, path-absolute, path-noscheme, path-rootless, path-empty) to resolve ambiguities. A path segment character is: pchar = unreserved / pct-encoded / sub-delims / ":" / "@".
The port subcomponent is defined as port = *DIGIT, an optional decimal number following the host delimited by a single colon. Producers and normalizers should omit the port and its ":" delimiter when the port is empty or equals the scheme's default.
The query component begins at the first "?" character and is terminated by "#" or end of URI. ABNF: query = *( pchar / "/" / "?"). The fragment begins at "#" and extends to end of URI. ABNF: fragment = *( pchar / "/" / "?").
The query component begins with "?" and is terminated by "#" or end of URI: query = *( pchar / "/" / "?" ). The fragment component begins with "#" and extends to end of URI: fragment = *( pchar / "/" / "?" ).
The query component is indicated by "?" and terminated by "#" or end of URI: query = *( pchar / "/" / "?"). The fragment component is indicated by "#" and terminated by end of URI: fragment = *( pchar / "/" / "?").
The query component (query = *( pchar / "/" / "?" )) begins at the first "?" and ends at "#" or end of URI. The fragment component (fragment = *( pchar / "/" / "?" )) begins at "#" and extends to end of URI; both allow "/" and "?" as data characters.
The scheme component begins with a letter followed by letters, digits, "+", "-", or ".". The ABNF is: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive; canonical form is lowercase.
The scheme component grammar is: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ), beginning with a letter. Canonical form is lowercase; implementations should accept uppercase as equivalent but must only produce lowercase scheme names.
The scheme component is defined as: scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive; the canonical form is lowercase, and documents specifying schemes MUST use lowercase letters.
The scheme component must begin with a letter and may be followed by letters, digits, plus ("+"), period ("."), or hyphen ("-"): scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ). Schemes are case-insensitive but the canonical form is lowercase.
The URI generic syntax defines five hierarchical components: URI = scheme ":" hier-part ["?" query] ["#" fragment]. The scheme and path are required; authority, query, and fragment are optional.
The URI generic syntax is defined as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ], where hier-part covers authority+path variants. The scheme and path components are required; path may be empty.
Unreserved characters (ALPHA / DIGIT / "-" / "." / "_" / "~") may appear in a URI without percent-encoding. A URI differing only in whether an unreserved character is percent-encoded identifies the same resource.
Unreserved characters (ALPHA, DIGIT, "-", ".", "_", "~") may appear unencoded in a URI; their percent-encoded equivalents identify the same resource. ABNF: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~".
Unreserved characters are defined as: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~". URIs that differ only in the replacement of an unreserved character with its percent-encoded equivalent identify the same resource.
Unreserved characters — unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" — may appear in a URI without encoding. URIs that differ only in whether an unreserved character is percent-encoded or literal are equivalent and identify the same resource.