Skip to content
Home

Uniform Resource Locator (URL): structure, purpose, history and usage

A Uniform Resource Locator (URL) identifies and locates resources on the Internet. This article explains URL structure, common uses, history, examples, and distinctions such as URL vs URI.

Overview

A Uniform Resource Locator, commonly called a URL or web address, is a standardized string that identifies where a resource lives on a network and how to retrieve it. People see and use URLs every day when they type an address into a web browser, click a hyperlink, or share a link. A URL encodes both the location of a resource and the protocol or method used to access it.

Image gallery

1 Image

Core components

Most URLs follow a recognizable pattern made of several parts that together describe access to a resource. These elements can appear in different combinations, but these are the common components:

  • Scheme (protocol): Specifies the protocol or access method, such as http or https. The scheme is followed by a colon.
  • Authority: Often includes optional user information, a host name or IP address, and an optional port number. The authority is usually preceded by ://.
  • Path: Describes the hierarchical location of the resource on the host, similar to a file path on a computer.
  • Query string: Optional data passed to the resource, introduced by a question mark (?), commonly used to send parameters to web applications.
  • Fragment: An optional identifier after a hash sign (#) that points to a subsection or location inside the returned document.

Example (schematic): https://example.com:443/path/to/page?name=value#section. Each piece has a specific interpretation and role when a client requests the resource.

How URLs are used in practice

Web browsers, command-line tools, scripts, email clients and many other programs interpret URLs to fetch documents, images, downloadable files, API endpoints and other networked resources. Links embedded on web pages use either absolute URLs, which fully specify scheme and authority, or relative URLs, which omit context that the client derives from the current document.

URLs also appear in application programming interfaces (APIs), automated workflows, and secure services. When special characters are required in a URL, they are encoded using percent-encoding; internationalized domain names are represented with Punycode or Unicode-aware systems to support non-ASCII characters.

History and standards

The URL concept emerged with the early World Wide Web. It was designed to give each resource a simple, human-readable address that could be resolved by a client and server. Over time the syntax and interpretation of URLs were refined and captured in Internet specifications so that different software implementations behave consistently. Modern standards separate the abstract idea of a resource identifier from the more specific URL syntax, but the familiar form continues to be the most widely used on the web.

Distinctions and notable facts

Two terms are often compared: URL and URI (Uniform Resource Identifier). A URL is a type of URI that, in addition to identifying a resource, provides a means to locate it. Not every URI is a URL; some URIs are simply names without a direct retrieval method. Web addresses can include sensitive data like username:password in legacy forms, but embedding credentials in URLs is discouraged for security reasons.

Further reading and resources

For technical definitions and syntax rules see formal specifications and tutorials. For basic explanations and examples consult an introductory resource: URL basics. For developer guidance on encoding and parsing try developer documentation. For information about web servers and how they resolve URLs see server guides. For notes on hyperlinking and HTML best practices visit linking practices. For background history and original proposals see archival material at historical notes. For internationalized domain names and character encoding references see IDN resources. For debates and clarifications on URL/URI terminology consult terminology discussion.

Structure

The basic URL structure consists of a scheme name defining the access method and a scheme-specific part separated by a colon:

<scheme>:<scheme-specific-part>

where scheme is often, but not necessarily, the same as the underlying network protocol (for example, ftp or http are, but mailto or file are not).

Possible URL parts are for example at http:

       |------------------ scheme-specific part ------------------| https://max:[email protected]:8080/index.html?p1=A&p2=B#ressource \___/ \_/ \____/ \_____________/ \__/\_________/ \_______/ | | | | | scheme⁺ | password host port path query fragment user (equal to network protocol here)

at mailto:

mailto:[email protected] \____/ \______________/ | schema⁺ | email address according to RFC 5322 (no network protocol here).

for news (neither a network protocol nor a host address is included in this example):

 news:alt.hypertext \__/ \___________/ | schema | newsgroup name

on file:

 file:///directory/subdirectory/file \__/ \___________________________________/ | | scheme | Path to a local file in the file system of the computer interpreting the URL

Strictly speaking, this scheme has the form file://<host>/<path> , but the host part is practically not used, since the file scheme can hardly be used meaningfully over a network due to the lack of a way to specify a network protocol for accessing the file. File URLs are used, for example, in the Java programming language to access local files in this way. Depending on the browser, opening file links is often only possible after special client-side configuration or with the help of add-ons etc.

Scheme (scheme)

Specifies the technical method with which the resource is to be addressed. This is usually, but not necessarily, the same as the network protocol used to locate the resource. Examples are HTTP, HTTPS or FTP, but also mailto (for writing an e-mail) or file (for accessing local files).

Scheme-specific part (scheme-specific part)

Depending on the scheme, different specific specifications are required and possible. In most cases, it starts with the character string //, but some variants also define only the colon. The following examples refer to the Hypertext Transfer Protocol (HTTP).

User and password (user, password)

If required, login information consisting of user name (user) and password (password) can also be transmitted. These are separated from each other by a colon and prefixed to the host with a separating at sign (@).

Even though the HTTP protocol was chosen for this example, specifying the user name and password as part of the URL is not part of the HTTP specification! Current browsers accept this URL syntax, but ask the user whether he really wants to log in with the specified data. Internet Explorer 6 (Windows XP SP2 and later) and newer versions are out of the ordinary in that they reject this URL syntax outright as incorrect. With a registry entry you can force them to behave in the same way as their predecessors up to version 5.5: These take over the login data without being asked and pass them directly to the server.

However, for some other protocols, such as FTP, the specification of user data in the form shown is perfectly correct and covered by the standards.

Host

The host component is noted in the form of an IPv4 address in decimal notation separated by periods, in the form of an IPv6 address in hexadecimal notation separated by colons and enclosed in square brackets, or in the form of an FQDN.

Port

The specification of the port allows the control of a TCP port. If no port is specified, the default port of the respective protocol is used - for example, HTTP 80, HTTPS 443 and FTP 21.

Path (Path)

The path describes a specific resource (this can, for example, coincide with the directory structure of the target system, such as a file or directory) on the server. The path can also be empty. An empty path can optionally be replaced by a slash and is equivalent to this.

The interpretation (file or directory; deliver text file or execute script) is left to the server. A typical example of the freedom of interpretation is the behavior when a client requests the path /: Depending on the setting, the server may deliver the contents of a named file (such as /index.html, /README, /HEADER) without this being apparent to the requesting client. In the same way, however, the server can - depending on the protocol - also explicitly forward to this resource or output a directory listing.

Query

Main article: Query String

In the case of HTTP, a query string can follow the actual resource pointer - separated by a question mark. This can be used to transfer additional information that can be processed further on the server or client side.

Fragment

Main article: Fragment identifier

After a double cross, a part of the resource can be referenced, typically an anchor in an HTML page, which is automatically scrolled down to after the page is called: The URL http://example.com/dokument.html#absatz3 would, in the fictional document here, cause the browser to scroll to the beginning of the third paragraph.

Examples

  • ftp://max:[email protected] ... FTP with user and password
  • http://de.wikipedia.org ... Website without path (calling the start page)
  • http://de.wikipedia.org/wiki/Uniform_Resource_Locator ... Website with path
  • https://de.wikipedia.org ... like calling up the website without specifying the path, but using the encrypted Hypertext Transfer Protocol Secure
  • mailto:[email protected] ... to write an e-mail to the specified mail address (opens the standard mail client with a new, empty message in which the TO address is pre-filled)
  • news:alt.hypertext ... Display of a Usenet newsgroup (generic, without specification of the network protocol NNTP)
  • nntp:alt.hypertext ... Display of a Usenet newsgroup (with specification of the network protocol NNTP)
  • telnet:example.org ... start a telnet session
  • file:///foo/bar.txt ... Access to a local file

Questions and answers

Q: What is a Uniform Resource Locator (URL)?

A: A URL is another name for a web address. It is made up of letters, numbers and other symbols in a standard form that people use to make computers fetch and show specific resources from the internet.

Q: What are the components of a URL?

A: URLs consist of several parts including a protocol (often Hypertext Transfer Protocol), separation characters, the other computer's name or address, path to document or script, username and password needed to access certain page, and text after pound sign (#).

Q: What does "www" stand for?

A: WWW stands for World Wide Web.

Q: What is the difference between an absolute URL and relative URL?

A: An absolute URL contains all the information necessary to locate a resource on the Internet while relative URLs can only be used when context can fill in missing information.

Q: Is there any difference between URI and URL?

A: URI stands for Uniform Resource Identifier which is basically same as URL so there isn't much difference between them.

Q: How do people use URLs?

A: People use URLs by typing them into web browsers or clicking links on web pages they are already viewing.

Related articles

Author

AlegsaOnline.com Uniform Resource Locator (URL): structure, purpose, history and usage

URL: https://en.alegsaonline.com/art/102863

Share

Sources