WebBuilding

Foundations

HTTP (Hypertext Transfer Protocol)

Summary

HTTP (Hypertext Transfer Protocol) is the set of rules browsers and web servers use to request and deliver web pages, images and other files. Tim Berners-Lee wrote the first version at CERN in 1990, and it has since passed through HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2 and HTTP/3, the last published in June 2022. HTTPS is the same protocol sent over an encrypted TLS connection.

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

What HTTP is

HTTP, short for Hypertext Transfer Protocol, is the set of rules a web browser and a web server follow when they exchange files. A protocol is an agreed format for messages, so that two programs written by different people can understand each other.

HTTP works as a conversation of requests and responses. The browser, called the client, asks for something, and the server answers. MDN Web Docs, Mozilla’s reference for web developers, describes HTTP as a client-server protocol in which requests are started by the recipient, usually the browser.1

One web page usually takes many requests. The browser first fetches the HTML document, reads it, and then sends more requests for the scripts, CSS style sheets, images and videos the page uses.1

Each request names a resource by its address, its URL, and gives a method that says what the client wants done. Each response opens with a three-digit status code that says how the request went. Both can carry headers: labeled lines of extra information, such as the type of file being sent.2

HTTP is stateless, which means the protocol itself keeps no link between one request and the next.1 The current standard defines it as “a stateless application-level protocol for distributed, collaborative, hypertext information systems.”3 Sites that need to remember a visitor, for a login or a shopping cart, add that memory with HTTP cookies.1

Methods and status codes, explained simply

The method is the verb of a request. HTTP/1.0 defined three of them in 1996: GET, HEAD and POST.2 The 1999 HTTP/1.1 standard listed eight, adding OPTIONS, PUT, DELETE, TRACE and CONNECT.4 PATCH, for changing part of a resource, was added by a separate standard in March 2010.5

MethodWhat it asks the server to doEveryday example
GETSend a copy of the resourceOpening a page or loading an image
HEADSame as GET, but send only the headers, no bodyChecking whether a file has changed
POSTAccept data from the client, often changing something on the serverSending a contact form or placing an order
PUTReplace the resource with the data sentUploading a file through an API
PATCHChange part of the resourceEditing one field of a record through an API
DELETEDelete the resourceRemoving an item through an API
OPTIONSDescribe the communication options for the resourceAsking what a server allows

The descriptions follow MDN’s method reference.6 An API (application programming interface) is a set of addresses that programs, rather than people, use to read and change data.

The status code comes first in every response. Its first digit places it in one of five classes, a scheme already set out in HTTP/1.0.2

ClassMeaningCommon codes
1xxInformational: an interim message before the final answer103 Early Hints
2xxSuccess200 OK
3xxRedirection: further action is needed, usually going to another address301 Moved Permanently, 302 Found, 304 Not Modified
4xxClient error: a problem with the request404 Not Found, 410 Gone
5xxServer error: a problem on the server’s side500 Internal Server Error, 503 Service Unavailable

MDN groups the codes the same way, from informational responses (100 to 199) to server errors (500 to 599).7 A few codes matter to every site owner. 301 means a page has moved for good, and the response gives the new address. 302 means the move is temporary.7 404 means the server cannot find what was asked for, while 410 says the content was deleted on purpose and has no forwarding address.7

500 is a generic failure inside the server. 503 means the server is not ready, most often because it is down for maintenance or overloaded.7 304 Not Modified is a caching code: it tells the browser that the copy it saved earlier is still good, so the file does not have to be sent again.7

103 Early Hints, published as an experimental RFC (RFC 8297) in December 2017, lets a server send hints that help the browser prepare while the full response is still being built.8

HTTP/0.9 and HTTP/1.0: the early web (1990 to 1996)

Tim Berners-Lee wrote the first web client and server in 1990.9 By the end of that year both were running at CERN, where he worked.10

The protocol they spoke was tiny. W3C’s archived page “The Original HTTP as defined in 1991” shows a request made of the word GET, a space and the document’s address.11 There were no headers and no status codes. The server sent the document and closed the connection, and the only way to tell an error from a real page was to read the text.11 The same page names this subset HTTP 0.9.11

As the web spread, developers added features by trial and use before they were written down.12 A 1992 draft on the W3C site, “Basic HTTP as defined in 1992”, already had sections on request methods, response status codes and headers.13

The IETF (Internet Engineering Task Force), which publishes the internet’s technical standards, first documented the protocol in May 1996. Its specifications appear as numbered RFCs, short for Request for Comments. RFC 1945 covered both HTTP/0.9 and HTTP/1.0 and stated that HTTP had been in use on the web since 1990.2 It was published as an informational document, not as a formal standard.2

HTTP/1.0 put a version number on each request, a status line at the top of each response and headers on both.2 The Content-Type header, which names the kind of file being sent, meant HTTP could carry files other than plain HTML.12

HTTP/1.1: the long-lived standard (1997 to 2022)

HTTP/1.1 was first published as RFC 2068 in January 1997, this time on the IETF standards track.14 RFC 2616 replaced it in June 1999.4 That document stayed the main definition of HTTP until June 2014.15

Three changes in HTTP/1.1 shaped how websites are hosted:

  • The Host header. Each request must name the website it is meant for.14 This made it possible to host many domain names on one server at one IP address.12
  • Persistent connections. One connection can carry several requests and responses instead of closing after each file.14 MDN notes that this saved the time spent opening a new connection for every image and script on a page.12
  • Chunked transfer. A server can send a response in pieces before it knows the total size. Every HTTP/1.1 program must be able to receive this.14

In June 2014 the IETF rewrote HTTP/1.1 as six documents, RFC 7230 to RFC 7235, which made RFC 2616 obsolete.1516 In June 2022 it reorganized HTTP again. RFC 9110 now defines what HTTP messages mean, RFC 9111 covers caching, and RFC 9112 covers the HTTP/1.1 message format.31718

HTTP/2 and HTTP/3: faster delivery

On November 11, 2009, Google engineers Mike Belshe and Roberto Peon announced SPDY, an experimental protocol for carrying web content with less delay. It sent many streams over one connection, let the browser set priorities and compressed headers. In Google’s lab tests on 25 top websites, pages loaded up to 55% faster.19

SPDY became the starting point for HTTP/2.12 The IETF published HTTP/2 as RFC 7540 in May 2015, with Belshe and Peon as two of its three authors.20

HTTP/2 keeps the meaning of HTTP but changes how messages travel. They are sent in a binary format rather than as text. Each request and response gets its own stream, and many streams share one connection, which is called multiplexing. Headers are compressed with a scheme called HPACK.20

HTTP/2 also added server push, which let a server send files before the browser asked for them.20 Few sites used it. Google reported that only 1.25% of HTTP/2 sites did, and it announced that Chrome 106 would turn push off by default, pointing developers to 103 Early Hints instead.21 A revised standard, RFC 9113, replaced RFC 7540 in June 2022 and deprecated HTTP/2’s original priority signals.22

HTTP/2 still ran over TCP, the internet’s standard way of delivering data in order. TCP cannot see the separate streams inside a connection, so, in the words of the HTTP/3 standard, “a lost or reordered packet causes all active transactions to experience a stall.”23 This problem is known as head-of-line blocking.

HTTP/3 avoids it by running over QUIC, a transport protocol built on UDP that the IETF published as RFC 9000 in May 2021.24 QUIC keeps each stream reliable on its own, so a lost packet holds up only the stream it belongs to.23

HTTP/3 itself was published as RFC 9114 in June 2022. It replaces HPACK with a compression scheme called QPACK, designed for QUIC’s out-of-order delivery. A server usually announces HTTP/3 in an Alt-Svc response header, and the browser can then try a QUIC connection.23

As of October 22, 2026, W3Techs detects HTTP/3 on 41.1% of websites and HTTP/2 on 35.0%. W3Techs notes that one site can use more than one of the features it tracks, so these percentages are not meant to add up to 100%.25

How HTTPS relates to HTTP

HTTPS is not a different protocol. It is ordinary HTTP sent inside an encrypted connection made with TLS (Transport Layer Security). RFC 2818, published in May 2000, described “how to use TLS to secure HTTP connections over the Internet” and made port 443 the default.26

A port is a numbered entry point on a server. An http:// address uses TCP port 80 unless it says otherwise, and an https:// address uses port 443.3 Since June 2022, RFC 9110 has defined the https scheme itself, and it made RFC 2818 obsolete.3

Under RFC 9110, an https connection counts as secured only when the server has been authenticated as acting for the site named in the address and the exchange has acceptable confidentiality and integrity protection.3 With HTTP/3, that protection sits in the transport layer: RFC 9000 describes QUIC as a secure transport.24

HTTPS is now the normal case. As of October 22, 2026, W3Techs finds that 90.3% of websites use https as their default protocol.25 Certificates, the padlock and the move from SSL to TLS 1.3 are covered in the entry on HTTPS and TLS.

Timeline

  1. RFC 9110 to RFC 9114 reorganize HTTP and publish HTTP/3 as RFC 911423
  2. QUIC, the transport under HTTP/3, is published as RFC 900024
  3. RFC 8297 defines status code 103 Early Hints8
  4. HTTP/2 is published as RFC 754020
  5. HTTP/1.1 is rewritten as RFC 7230 to RFC 723516
  6. RFC 5789 adds the PATCH method5
  7. Google announces SPDY, the forerunner of HTTP/219
  8. RFC 2818 describes HTTP over TLS on port 44326
  9. RFC 2616 becomes the main HTTP/1.1 standard4
  10. HTTP/1.1 is first published as RFC 206814
  11. RFC 1945 documents HTTP/1.02
  12. A draft "Basic HTTP" adds methods, status codes and headers13
  13. The original one-line protocol, later called HTTP/0.9, is described11
  14. Tim Berners-Lee writes the first web client and server9

What it means for your website

You rarely set up HTTP yourself, but its status codes and versions shape how your site behaves for visitors and search engines.

  • Use the right redirect. When a page moves for good, for example during a website migration, send a 301 from the old URL to the new one. Save 302 for moves that really are temporary.7
  • Retire pages on purpose. A 404 says a page cannot be found, and a 410 says it was removed deliberately.7 Check that your “page not found” screen returns a real 404 status, not 200.
  • Use 503 for planned downtime. It tells browsers and crawlers that the server is temporarily not ready, for example during maintenance.7
  • Serve every page over HTTPS. Install an SSL/TLS certificate and 301-redirect every http:// address to its https:// version. As of October 22, 2026, 90.3% of websites already default to https.25
  • Check which version you get. In Chrome, open DevTools, go to the Network panel, right-click the column header and turn on Protocol. h2 means HTTP/2 and h3 means HTTP/3.27 HTTP/3 has to be offered by the server, which advertises it to browsers.23 If you see neither, ask your host or your CDN whether they support it.

Our guide to how a website works shows where HTTP sits between your domain, your host and a visitor’s browser.

See also

References

  1. Overview of HTTP. MDN Web Docs, Mozilla. accessed October 22, 2026.
  2. RFC 1945: Hypertext Transfer Protocol, HTTP/1.0. Internet Engineering Task Force, RFC Editor. 1996-05. accessed October 22, 2026.
  3. RFC 9110: HTTP Semantics. Internet Engineering Task Force, RFC Editor. 2022-06. accessed October 22, 2026.
  4. RFC 2616: Hypertext Transfer Protocol, HTTP/1.1. Internet Engineering Task Force, RFC Editor. 1999-06. accessed October 22, 2026.
  5. RFC 5789: PATCH Method for HTTP. Internet Engineering Task Force, RFC Editor. 2010-03. accessed October 22, 2026.
  6. HTTP request methods. MDN Web Docs, Mozilla. accessed October 22, 2026.
  7. HTTP response status codes. MDN Web Docs, Mozilla. accessed October 22, 2026.
  8. RFC 8297: An HTTP Status Code for Indicating Hints. Internet Engineering Task Force, RFC Editor. 2017-12. accessed October 22, 2026.
  9. Tim Berners-Lee. World Wide Web Consortium (W3C). accessed October 22, 2026.
  10. A short history of the Web. CERN. accessed October 22, 2026.
  11. The Original HTTP as defined in 1991. World Wide Web Consortium (W3C). 1991. accessed October 22, 2026.
  12. Evolution of HTTP. MDN Web Docs, Mozilla. accessed October 22, 2026.
  13. Basic HTTP as defined in 1992. World Wide Web Consortium (W3C). 1992. accessed October 22, 2026.
  14. RFC 2068: Hypertext Transfer Protocol, HTTP/1.1. Internet Engineering Task Force, RFC Editor. 1997-01. accessed October 22, 2026.
  15. Information on RFC 2616. RFC Editor. accessed October 22, 2026.
  16. RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. Internet Engineering Task Force, RFC Editor. 2014-06. accessed October 22, 2026.
  17. RFC 9111: HTTP Caching. Internet Engineering Task Force, RFC Editor. 2022-06. accessed October 22, 2026.
  18. RFC 9112: HTTP/1.1. Internet Engineering Task Force, RFC Editor. 2022-06. accessed October 22, 2026.
  19. A 2x Faster Web. Mike Belshe and Roberto Peon, The Chromium Blog, Google. 2009-11-11. accessed October 22, 2026.
  20. RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2). Internet Engineering Task Force, RFC Editor. 2015-05. accessed October 22, 2026.
  21. Remove HTTP/2 Server Push from Chrome. Barry Pollard, Chrome for Developers, Google. 2022-08-18. accessed October 22, 2026.
  22. RFC 9113: HTTP/2. Internet Engineering Task Force, RFC Editor. 2022-06. accessed October 22, 2026.
  23. RFC 9114: HTTP/3. Internet Engineering Task Force, RFC Editor. 2022-06. accessed October 22, 2026.
  24. RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport. Internet Engineering Task Force, RFC Editor. 2021-05. accessed October 22, 2026.
  25. Usage statistics of site elements for websites. W3Techs. 2026-10-22. accessed October 22, 2026.
  26. RFC 2818: HTTP Over TLS. Internet Engineering Task Force, RFC Editor. 2000-05. accessed October 22, 2026.
  27. Network features reference. Chrome for Developers, Google. 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].