WebBuilding

Foundations

URL

Summary

A URL (Uniform Resource Locator) is the address of a resource on the web, such as https://www.example.com/about. It names the scheme used to fetch the resource, the host that holds it and the path to it, with an optional port, query and fragment. Tim Berners-Lee devised the format for the World Wide Web, the name URL was agreed at an IETF meeting in July 1992, and RFC 1738 first standardized it in December 1994. Today the generic syntax is RFC 3986 (2005), while browsers follow the WHATWG URL Standard.

Web Building Encyclopedia · Foundations · Last reviewed October 22, 2026 · 10 min read

What a URL is

A URL, short for Uniform Resource Locator, is the address of something on the web: a page, an image, a style sheet or a downloadable file. MDN Web Docs defines it as the address of a unique resource on the internet, and notes that browsers use URLs to retrieve pages, CSS documents, images and other resources.1

A URL is written as one line of text, but it is built from separate parts, each with its own job. RFC 3986, the Internet standard for the general syntax, names five main components: scheme, authority, path, query and fragment.2 It shows them in a single example address, foo://example.com:8042/over/there?name=ferret#nose.2

The rules for writing URLs come from two places today. The Internet Engineering Task Force (IETF) publishes the formal syntax as numbered RFC documents, and the WHATWG maintains the URL Standard, which describes how web browsers actually read addresses.23

The parts of a URL

Take the made-up address https://www.example.com:443/guides/url?lang=en#history. Read from left to right, it breaks into six pieces:

PartIn the exampleWhat it does
SchemehttpsNames the protocol used to fetch the resource1
Hostwww.example.comNames the server, as a domain or an IP address3
Port443Picks the network port on that server; usually left out1
Path/guides/urlIdentifies the resource on the server1
Querylang=enPasses extra parameters after a question mark1
FragmenthistoryPoints to a spot inside the resource, after a # sign1

Scheme. The scheme comes first and ends with a colon. For websites it is usually https or its unencrypted form, http, though browsers also understand others such as mailto: for email addresses.1 RFC 3986 says schemes are case-insensitive but that lowercase is the canonical form.2

Host and authority. Two slashes introduce the authority: the host, an optional port and, rarely, a user name and password written before an @ sign. MDN describes that last form as deprecated for security reasons.1 The host can be a domain name or an IP address.3 RFC 3986 says the host is case-insensitive, so EXAMPLE.com and example.com name the same machine.2

Port. A port number tells the server which service the visitor wants. Each scheme can have a default: RFC 9110, the current definition of HTTP, makes TCP port 80 the default for http and port 443 the default for https.4 The URL Standard also lists 21 for ftp and 80 and 443 for the ws and wss WebSocket schemes.3 When the default is used, the port is normally left out, and RFC 3986 treats http://example.com/ and http://example.com:80/ as equivalent.12

Path. The path often looks like a list of folders, but it does not have to match real folders on a disk. MDN says it is “mostly an abstraction handled by Web servers without any physical reality.”1

Query. The query starts with a question mark and usually holds key and value pairs joined by an ampersand, such as ?key1=value1&key2=value2. Each web server sets its own rules for what the parameters mean.1

Fragment. RFC 3986 says the fragment is separated from the rest of the URI before the resource is fetched and is handled only by the user agent, meaning the browser.2 In practice it is never sent to the server; in an HTML page the browser uses it to scroll to the matching spot.1 Berners-Lee chose the # sign by analogy with the number sign used for an apartment or suite in US postal addresses.5

A link inside a page does not have to spell out every part. A relative URL such as /contact or ../pricing borrows the missing pieces from the address of the page that contains it.1

From UDI to URL, 1991 to 1994

The addressing scheme grew out of Tim Berners-Lee‘s work on the World Wide Web at CERN. W3C’s history of the subject starts with his notes on document naming from 1991.6 A November 1992 copy of the project’s own pages calls web addresses hypertext names and gives the pattern as scheme, then //, then host.domain:port, then the path, then # and an anchor.7

The double slash was borrowed. Berners-Lee wanted to separate the part of the address a browser must understand, the host name, from the rest, and he copied the // from the way the Apollo computer system named files across its network.5 Looking back, he wrote that he regrets how clumsy the syntax turned out to be.5

On February 27, 1992, Berners-Lee posted a draft discussion paper, “Universal Document Identifiers on the Network,” to the www-talk mailing list. It proposed one addressing scheme for archived files, news articles and groups, Gopher items, WAIS indexes, queries and documents.8 His FAQ describes UDI as the name that later became URL, and then URI.5

The name changed at a “birds of a feather” session, an informal meeting held to test interest in new IETF work. Berners-Lee’s announcement set the UDI session for Monday, July 13, 1992.9 The minutes date it to July 14, 1992, at the 24th IETF meeting in Cambridge, Massachusetts, and record that “URL was decided on by an almost unanimous vote.”10 The group also agreed that the scheme prefix should come first, followed by a colon, and that addresses should be short strings a person could type.10

Two documents followed in 1994. In June, Berners-Lee published RFC 1630, “Universal Resource Identifiers in WWW.” It was informational, not a standard, and it used URI as the umbrella term while calling the URIs that refer to objects reached with existing protocols Uniform Resource Locators.11 The IETF’s URI working group, formed in March 1994, then produced RFC 1738, “Uniform Resource Locators (URL),” in December 1994.612

RFC 1738 was edited by Berners-Lee of CERN, L. Masinter of Xerox and M. McCahill of the University of Minnesota. It defined a URL as a scheme name, a colon and a scheme-specific part, described ten schemes (ftp, http, gopher, mailto, news, nntp, telnet, wais, file and prospero), and set 80 as the default port for http.12 It required unsafe characters such as spaces, quote marks, # and % to be written as a % sign followed by two hexadecimal digits.12

The RFC Editor now lists RFC 1738 as obsoleted by RFCs 4248 and 4266 and updated by several later documents, including RFC 3986.13

URL, URI and URN

Three related terms are easy to mix up. A URI, or Uniform Resource Identifier, is any string that identifies a resource. RFC 3986 says a URI can be a locator, a name or both.2

  • URL. In RFC 3986, the subset of URIs that also give a way to locate the resource, for example by its network location.2
  • URN. A Uniform Resource Name. RFC 8141, published in April 2017, defines a URN as a persistent identifier that does not depend on where the resource is stored, such as urn:example:foo.14

In the early 1990s, many people expected every identifier scheme to be either a URL or a URN. A third class, the URC (Uniform Resource Characteristics) for pointing to a resource’s metadata, was proposed but won no support.15 An August 2002 report from a joint W3C and IETF group, published as RFC 3305, called this the classical view.15

The same report set out a contemporary view in which http: and urn: are simply two URI schemes, and urn:isbn is a namespace inside urn: rather than a scheme of its own. It concluded: “URL is a useful but informal concept.”15

The generic syntax went through three versions. Roy Fielding’s RFC 1808 added relative URLs in June 1995, and RFC 2396, by Berners-Lee, Fielding and Masinter, set out a generic URI syntax in August 1998.6 RFC 3986, by the same three authors, replaced RFC 2396 and RFC 1808 in January 2005 and became Internet Standard 66 (STD 66).2

The WHATWG URL Standard goes the other way. It uses the word URL for everything and calls the terms URI and IRI confusing, since one algorithm handles both anyway.3

The WHATWG URL Standard and browsers

Browsers did not always read addresses the way the RFCs said they should. A 2015 IETF draft by Sam Ruby and Larry Masinter reported that popular browsers and software libraries did not agree with each other on how to handle URLs, and that HTML specifications had redefined URL to match what some browsers did.16

The WHATWG’s answer is the URL Standard. One of its stated goals is to “Align RFC 3986 and RFC 3987 with contemporary implementations and obsolete the RFCs in the process.”3 Anne van Kesteren wrote in a post dated January 2, 2013, that he had started writing the URL Standard after the summer vacation period, and that the NLnet Foundation had accepted his proposal for three months of work on WHATWG standards.17

It is a living standard, revised as needed rather than in numbered versions; as of October 22, 2026, it was last updated on October 19, 2026.3 It describes a URL as a scheme, username, password, host, port, path, query and fragment, and it sets out a single parsing algorithm for turning text into those parts.3

The standard also defines the URL interface used by JavaScript. Code such as new URL(“cats”, “http://www.example.com/animals/dogs”) parses an address against a base and exposes parts like protocol, hostname, pathname, search and hash.18 MDN lists the interface as widely available across browsers since July 2015.18

Characters beyond ASCII

URLs were designed around a small set of plain ASCII characters, so anything else has to be encoded.

Percent-encoding

Percent-encoding writes a byte as a % sign followed by two hexadecimal digits. In RFC 3986, %20 stands for the space character, and the RFC asks for uppercase hex digits for consistency.2 Some characters are reserved because they separate the parts of a URL, among them : / ? # [ ] and @. A reserved character used as ordinary data has to be percent-encoded.2

RFC 3987, published alongside RFC 3986 in January 2005, defined Internationalized Resource Identifiers (IRIs), a complement to URIs that can contain characters from any script. To turn an IRI into a URI, each character is first converted to UTF-8 bytes, and those bytes are then percent-encoded.19 The letter é, for example, becomes %C3%A9, so café in a path is written caf%C3%A9.19

Internationalized domain names

Domain names took a different route. RFC 3490, published in March 2003, defined Internationalizing Domain Names in Applications (IDNA), a method designed to work without any changes to DNS servers, resolvers or the DNS protocol.20 Instead, software converts a name into an ASCII form before looking it up in the DNS.20

That ASCII form uses Punycode, an encoding of Unicode described in RFC 3492, also from March 2003.21 Converted labels begin with the prefix xn--.20 RFC 5890, from August 2010, replaced RFC 3490 as part of a revision often called IDNA2008, and names the two forms the A-label (ASCII) and the U-label (Unicode).22 RFC 3986 says a non-ASCII host name meant to be looked up in the DNS must be converted to the IDNA encoding first.2

Here the IETF and browsers part ways. The WHATWG URL Standard says the web platform uses Unicode IDNA Compatibility Processing (UTS #46) “and not IDNA2008.” Its example turns ☕.example into xn--53h.example.3

Non-Latin scripts reached the top of the naming tree on May 5, 2010, when the first internationalized country-code top-level domains, for Egypt, Saudi Arabia and the United Arab Emirates, were added to the DNS root zone. All three are in Arabic script. ICANN described it as the first time in the history of the internet that non-Latin characters were used in top-level domains.23

Cool URIs and keeping addresses stable

A URL only works while the server behind it keeps answering. In “Cool URIs don’t change,” a page added to W3C’s style guide in December 1998, Berners-Lee argued that broken addresses come from people, not technology: “URIs don’t change: people change them.”246

He warned that when a link breaks, readers lose confidence in the owner of the server. His advice was to keep out of an address anything likely to change, such as the author’s name, the subject, the document’s status, a file extension such as .html and signs of the software in use such as cgi.24 A creation date, on the other hand, will not change, as in his example http://www.w3.org/1998/12/01/chairs.24 He also noted that redirection and proxying let a site hide many servers behind one stable set of addresses.24

The web’s own first address shows what is at stake. The first website lived at http://info.cern.ch/hypertext/WWW/TheProject.html. For many years that URL was inactive and sent visitors to the root of info.cern.ch, until CERN put the files back on April 29, 2013, using a 1992 copy from W3C’s archive.25

When an address does have to change, HTTP has a tool for it: the redirect. Google’s documentation counts HTTP status codes 301 and 308 as permanent redirects and 302, 303 and 307 as temporary ones. After a permanent redirect, Google treats the new address as the canonical one and shows it in search results.26

Timeline

  1. Latest update to the WHATWG URL Standard as of October 22, 20263
  2. RFC 8141 replaces RFC 2141 as the definition of Uniform Resource Names14
  3. CERN puts the files of the first website back at the first URL25
  4. Anne van Kesteren describes starting the WHATWG URL Standard17
  5. RFC 5890 revises internationalized domain names (IDNA2008)22
  6. First non-Latin country-code top-level domains enter the DNS root23
  7. RFC 3986 (STD 66) sets the URI generic syntax, and RFC 3987 defines IRIs2
  8. RFC 3490 and RFC 3492 define IDNA and Punycode20
  9. RFC 3305 calls URL "a useful but informal concept"15
  10. "Cool URIs don't change" is added to W3C's style guide6
  11. RFC 2396 publishes a generic URI syntax6
  12. RFC 1738 standardizes Uniform Resource Locators12
  13. Berners-Lee publishes RFC 1630, Universal Resource Identifiers in WWW11
  14. The UDI session at the 24th IETF votes for the name URL10
  15. Berners-Lee posts the draft "Universal Document Identifiers on the Network"8

What it means for your website

Every page on your site has a URL, and most of the choices about it are made once and then lived with for years. On a hosted builder the platform sets the overall pattern, but you usually choose the last part, often called the slug. On self-hosted WordPress you choose the whole structure.

  • Use readable words. Google advises readable words instead of long ID numbers, with hyphens rather than underscores between words.27 WordPress’s default “plain” format is ?p= followed by a post number; its post-name setting turns a title such as “This Is A Great Post” into this-is-a-great-post.28 We build on WordPress every week, and the post-name setting is the one we start from.
  • Leave out details that will change. Following Berners-Lee’s advice, keep file extensions, software names, author names and status words out of your addresses.24
  • Pick one version of every address. Google treats the http and https versions of a page as duplicates, and treats paths as case-sensitive, so /APPLE and /apple are two URLs.2927 WordPress’s redirect_canonical function, added in version 2.3, sends www or non-www requests and old ?p= links to the site’s chosen form, and applies your permalink setting’s trailing slash.30
  • Trim parameters. Google recommends dropping parameters that do not change the content and keeping session IDs out of URLs.27
  • Redirect, do not delete. If you rename pages or switch platforms, send each old address to its new one with a permanent server-side redirect. Google recommends this method whenever possible.26 Our guide to moving your website and the redesign checklist cover how to list your current URLs before you change anything.

The address people type first is your domain name, and it follows the same rule: keep it, and keep renewing it, for as long as the links to it matter.

See also

References

  1. What is a URL?. MDN Web Docs, Mozilla. accessed October 22, 2026.
  2. RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, R. Fielding and L. Masinter, IETF, RFC Editor. 2005-01. accessed October 22, 2026.
  3. URL Standard. WHATWG. 2026-10-19. accessed October 22, 2026.
  4. RFC 9110: HTTP Semantics. R. Fielding, M. Nottingham and J. Reschke (eds.), IETF, RFC Editor. 2022-06. accessed October 22, 2026.
  5. Frequently asked questions by the Press. Tim Berners-Lee, W3C. accessed October 22, 2026.
  6. Naming and Addressing: URIs, URLs, …. W3C. accessed October 22, 2026.
  7. W3 naming schemes (November 1992 snapshot of the first website). W3C. 1992-11. accessed October 22, 2026.
  8. Draft: Universal Document Identifiers. Tim Berners-Lee, www-talk mailing list, W3C archives. 1992-02-27. accessed October 22, 2026.
  9. IETF BOF on Universal Document Identifiers. Tim Berners-Lee, www-talk mailing list, W3C archives. 1992-06-26. accessed October 22, 2026.
  10. Minutes of the "UDI" BOF at the 24th IETF. Notes by Karen Sollins, edited by Tim Berners-Lee, W3C history archive. 1992-07. accessed October 22, 2026.
  11. RFC 1630: Universal Resource Identifiers in WWW. T. Berners-Lee, IETF, RFC Editor. 1994-06. accessed October 22, 2026.
  12. RFC 1738: Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter and M. McCahill (eds.), IETF, RFC Editor. 1994-12. accessed October 22, 2026.
  13. Information on RFC 1738. RFC Editor. accessed October 22, 2026.
  14. RFC 8141: Uniform Resource Names (URNs). P. Saint-Andre and J. Klensin, IETF, RFC Editor. 2017-04. accessed October 22, 2026.
  15. RFC 3305: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations. M. Mealling and R. Denenberg (eds.), Joint W3C/IETF URI Planning Interest Group, RFC Editor. 2002-08. accessed October 22, 2026.
  16. URL Problem Statement and Directions (draft-ruby-url-problem-01). S. Ruby and L. Masinter, IETF Datatracker. 2015-01-11. accessed October 22, 2026.
  17. NLnet. Anne van Kesteren, annevankesteren.nl. 2013-01-02. accessed October 22, 2026.
  18. URL (Web API reference). MDN Web Docs, Mozilla. accessed October 22, 2026.
  19. RFC 3987: Internationalized Resource Identifiers (IRIs). M. Duerst and M. Suignard, IETF, RFC Editor. 2005-01. accessed October 22, 2026.
  20. RFC 3490: Internationalizing Domain Names in Applications (IDNA). P. Faltstrom, P. Hoffman and A. Costello, IETF, RFC Editor. 2003-03. accessed October 22, 2026.
  21. RFC 3492: Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello, IETF, RFC Editor. 2003-03. accessed October 22, 2026.
  22. RFC 5890: Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin, IETF, RFC Editor. 2010-08. accessed October 22, 2026.
  23. First IDN ccTLDs Available. ICANN. 2010-05-05. accessed October 22, 2026.
  24. Hypertext Style: Cool URIs don't change. Tim Berners-Lee, W3C. 1998. accessed October 22, 2026.
  25. First URL active once more. Dan Noyes, CERN first website project (archived). 2013-04-29. accessed October 22, 2026.
  26. Redirects and Google Search. Google Search Central. 2026-04-14. accessed October 22, 2026.
  27. URL structure best practices for Google. Google Search Central. 2026-10-21. accessed October 22, 2026.
  28. Customize permalinks. WordPress.org Documentation. accessed October 22, 2026.
  29. What is URL canonicalization. Google Search Central. 2026-08-20. accessed October 22, 2026.
  30. redirect_canonical(). WordPress Developer Resources. accessed October 22, 2026.

Web Building Encyclopedia. First published October 22, 2026. Last reviewed October 22, 2026. Every fact on this page is linked to a source we opened. Spotted an error? Write to [email protected].