HTTP Explained: How Your Browser Actually Talks to the Web

Every time you open a web page, click a link, or submit a form, your browser has a short conversation with a server. That conversation follows a set of rules called HTTP, the Hypertext Transfer Protocol. It has been the primary way information moves across the World Wide Web since its introduction in 1990, starting with a single method, GET (IETF).

This article explains that conversation in plain language: what a request and a response look like, what the numbers in status codes mean, how HTTPS protects the exchange, and why newer versions of the protocol made the web noticeably faster.

Key Takeaways

• HTTP is a request and response protocol: the browser asks for something, the server answers with a status code, headers, and a body.

• HTTP itself is stateless, so cookies and sessions are the layer that remembers who you are between requests.

• HTTPS is HTTP wrapped in TLS encryption, and modern browsers expect it: HTTP traffic on port 80 should redirect to HTTPS on port 443.

• Caching lets browsers and CDNs reuse responses, which is one of the biggest wins for page speed.

• HTTP/2 multiplexes many requests over one connection, and HTTP/3 runs over QUIC instead of TCP, cutting connection delays further.

What Is HTTP?

HTTP is an application-layer protocol for fetching resources such as HTML documents, images, stylesheets, and scripts. It sits on top of a transport connection, usually TCP, and follows a simple pattern: a client sends a request, and a server sends back a response.

The protocol was born at CERN. Tim Berners-Lee proposed the hypertext system in March 1989, and the first version, HTTP/0.9, appeared in 1991 with only the GET method and no headers at all (SSD Nodes). HTTP/1.0 was defined by RFC 1945 in May 1996, and HTTP/1.1 followed with RFC 2068 in January 1997, then RFC 2616 in June 1999. The modern definition lives in RFC 9110, published in June 2022 as Internet Standard 97, which defines the semantics shared by HTTP/1.1, HTTP/2, and HTTP/3 (IETF).

One property shapes everything else about HTTP: it is stateless. As MDN Web Docs puts it, there is no link between two successive requests on the same connection. The server treats each request on its own, which keeps servers simple and scalable, and anything that needs memory, such as a login session, is handled by cookies or tokens sent along with each request.

Anatomy of a Request and a Response

A request has four parts. The first line carries the method, the path, and the version, for example GET / HTTP/1.1. Then come headers, key-value pairs such as Host and Accept that describe the request. An empty line separates the headers from the optional body, which carries data for methods such as POST.

A response mirrors that shape. Its first line carries the version, a three-digit status code, and a short reason phrase, for example HTTP/1.1 200 OK. Headers follow, then an optional body with the actual content. MDN Web Docs shows a sample response with a Content-Length of 29769 bytes, which tells the client exactly how much data to expect.

Before any of this happens, the browser needs to find the server. That lookup is the job of DNS, which turns a domain name into an IP address. If you want the full picture of that step, read DNS Explained: How the Internet Finds Every Website You Visit.

HTTP Methods: The Verbs of the Web

Methods tell the server what the client wants to do with a resource. The common ones are:

• GET: fetch a resource. Safe and idempotent, meaning it changes nothing and repeating it gives the same result.

• POST: submit data to be processed, such as a form or a file upload.

• PUT: replace a resource entirely with the data sent.

• PATCH: apply a partial change to a resource.

• DELETE: remove a resource.

• HEAD: like GET, but returns only the headers, useful for checking whether a resource changed.

• OPTIONS: ask the server which methods and features it supports for a resource.

GET and POST do most of the everyday work. The rest matter mainly when you build or consume an API, which is why they show up so often in REST API Explained: How the Web's Most Common API Style Actually Works.

Status Codes: What the Three Digits Mean

Every response carries a status code, and the first digit tells you the category:

A few codes deserve a closer look. 301 Moved Permanently tells clients and search engines that a resource has a new home for good, which is why it is the standard way to redirect plain HTTP to HTTPS. 304 Not Modified is the caching shortcut: the server tells the browser its stored copy is still fresh, so no body is sent at all. 404 Not Found means the server cannot find the requested resource, while 500 Internal Server Error means something went wrong on the server side and the client did nothing wrong.

Headers: The Metadata That Makes HTTP Work

Headers are the small print of every request and response. A few do heavy lifting:

• Host: names the website the request is for, which lets many sites share one server and IP address.

• Content-Type: tells the receiver what kind of data the body contains, such as text/html or application/json.

• Content-Length: states the body size in bytes.

• Accept: tells the server which formats the client can handle.

• Authorization: carries credentials, usually a token, for protected resources.

• Cache-Control: controls how responses may be stored and reused.

• Set-Cookie: asks the browser to store a cookie for later requests.

Headers are also where security policies travel. Strict-Transport-Security tells the browser to use HTTPS only, and Content-Security-Policy limits which sources a page may load. They are invisible to most users, but they shape much of what the web can and cannot do.

Stateless by Design, Stateful With Cookies

Because HTTP forgets each request, the web needed a memory. That memory is the cookie. When a server wants the browser to remember something, it sends a Set-Cookie header, and the browser sends the cookie back in a Cookie header on later requests (MDN Web Docs).

Cookies carry a few important attributes. Max-Age is measured in seconds, so Max-Age=2592000 means the cookie lives for 30 days, and a zero or negative value expires it immediately. If neither Expires nor Max-Age is set, the cookie is a session cookie that disappears when the browser closes. HttpOnly blocks JavaScript from reading the cookie, which protects it from cross-site scripting theft, Secure restricts it to HTTPS connections, and SameSite=None requires Secure to be set as well (MDN Web Docs).

In practice, cookies store a session identifier, and the real data lives on the server. That split keeps sensitive information off the client while still letting a site remember that you are logged in.

HTTPS: HTTP With a Lock on the Door

HTTPS is HTTP carried over TLS, the encryption layer that keeps requests and responses private and tamper-proof. The standard port for HTTPS is 443, defined by RFC 2818 in May 2000, while plain HTTP uses port 80 (SSD Nodes).

The practical rule from MDN Web Docs is simple: sites should redirect HTTP on port 80 to the same resource on HTTPS, typically with a 301 redirect. On top of that, HTTP Strict Transport Security (HSTS) tells browsers to refuse plain HTTP for a site. MDN recommends an HSTS max-age of at least 6 months (15768000 seconds), with 2 years (63072000 seconds) recommended, and inclusion in the HSTS preload list requires a max-age of at least 1 year (31536000 seconds) plus includeSubDomains.

TLS does three things at once: it encrypts the traffic so nobody on the network can read it, it authenticates the server through a certificate so you know you are talking to the real site, and it guarantees integrity so the data cannot be altered in transit. That is why browsers now mark plain HTTP pages as not secure.

Caching: The Web's Biggest Speed Shortcut

Fetching the same file again and again is wasteful, so HTTP has a built-in reuse system. There are two main cache types: private caches, typically the browser cache, and shared caches, such as proxies and CDNs (MDN Web Docs).

The Cache-Control header is the main control. Cache-Control: max-age=604800 tells a cache the response is fresh for 604800 seconds, or one week. When a cached response gets old, the browser can revalidate it with If-Modified-Since or If-None-Match, and if nothing changed the server answers 304 Not Modified with no body, saving a full download. When no Cache-Control is given, heuristic caching kicks in, recommending about 10 percent of the time since Last-Modified as the freshness lifetime (MDN Web Docs).

Good caching is invisible when it works and painful when it does not, which is why versioned file names and sensible max-age values are a standard part of shipping a fast site.

HTTP/1.1, HTTP/2, and HTTP/3: Three Generations

The protocol has evolved in three clear steps, each fixing the previous generation's bottleneck.

HTTP/1.1 introduced persistent connections, so one TCP connection could carry many requests in sequence instead of opening a new connection per request. But requests still queued one at a time on each connection, a problem known as head-of-line blocking, and browsers worked around it by opening several parallel connections.

HTTP/2, published as RFC 7540 in May 2015, multiplexes many requests and responses over a single connection, compresses headers, and lets servers push resources before the client asks. That removed most of the queuing, though head-of-line blocking could still happen at the TCP layer when a packet was lost.

HTTP/3, published as RFC 9114 in June 2022, moves the transport from TCP to QUIC, a protocol built on UDP that was standardized as RFC 9000 in May 2021. QUIC handles each stream independently, so a lost packet delays only its own stream, and connections can be established faster with fewer round trips (IETF).

Adoption has been quick. As of May 2022, HTTP/3 was already supported by browsers used by more than 72 percent of web users, and by June 2022 it was used by 25 percent of the top 10 million websites, according to W3Techs (IETF). A November 2026 snapshot of 219,633 crawled sites found 61.8 percent serving their main HTML over HTTP/2, 23.7 percent over HTTP/3, and 14.5 percent still on HTTP/1.1. Sites on HTTP/3 showed a median Time to First Byte of 530 ms, against 720 ms on HTTP/2 and 607 ms on HTTP/1.1 (corewebvitals.io).

Why HTTP Still Matters

HTTP looks simple from the outside, and that simplicity is the point. A client asks, a server answers, and everything else, encryption, caching, sessions, compression, is layered on top of that exchange. Every newer web technology, from REST APIs to real-time apps over WebSockets, starts with an HTTP handshake before it becomes something else.

If you build for the web, understanding HTTP pays off in everyday debugging: a 404 tells you the path is wrong, a 301 tells you the resource moved, a 304 tells you the cache did its job, and a slow Time to First Byte tells you where to look first. The protocol is over 30 years old, and it is still the conversation every web page starts with.

Read this article in Indonesian: HTTP Dijelaskan: Cara Browser Berkomunikasi dengan Web

Frequently Asked Questions

Is HTTP the same as the internet?

No. The internet is the network of networks, while HTTP is one protocol that runs on top of it, specifically for transferring web resources. Other protocols, such as DNS for name lookup and SMTP for email, share the same network.

What is the difference between HTTP and HTTPS?

HTTPS is HTTP encrypted with TLS. It uses port 443 instead of port 80, protects data from eavesdropping and tampering, and authenticates the server with a certificate.

Why is HTTP stateless?

Statelessness keeps servers simple: each request carries everything the server needs, so any server can handle any request without remembering previous ones. State is added on top with cookies and sessions when an app needs it.

Do I need to know HTTP to build websites?

You can build a basic site without thinking about it, but debugging, performance work, and API design all become much easier once you understand requests, status codes, headers, and caching.

Will HTTP/3 replace HTTP/2 everywhere?

Not overnight. HTTP/3 adoption is growing, with 23.7 percent of crawled sites serving their main HTML over it in November 2026, but HTTP/2 remains the most common version, and servers negotiate the best version both sides support.

Sources

• MDN Web Docs

• IETF, RFC 9110: HTTP Semantics

• IETF, HTTP updates and HTTP/3

• MDN Web Docs, HTTP Caching

• MDN Web Docs, TLS Configuration

• MDN Web Docs, Set-Cookie

• SSD Nodes, History of HTTP

• corewebvitals.io, HTML Document Protocol