What Is HTTP?

HTTP in Plain English

HTTP stands for HyperText Transfer Protocol. The name comes from the early web, when the main job was fetching hypertext documents linked together by URLs. Today the same protocol carries almost everything a web application needs: HTML, CSS, JavaScript, images, fonts, JSON API responses, file downloads, streaming video chunks, software update manifests, and telemetry beacons.

HTTP is an application layer protocol. It does not decide how packets move across the internet, how Wi-Fi transmits radio frames, or how TCP retransmits lost data. Instead, it defines the language used by web clients and servers once a network path already exists. A browser sends a request. A server sends a response. That simple pattern is the foundation of the modern web.

The Request and Response Model

An HTTP transaction starts with a client request. The request includes a method such as GET, POST, PUT, or DELETE; a path such as /guides/protocols/what-is-http; headers that describe the request; and sometimes a body containing submitted form data, JSON, or uploaded content. The server reads that request and returns a response with a status code, response headers, and usually a body.

Status codes tell the client what happened. 200 OK means the request succeeded. 301 and 302 redirect the browser to another URL. 404 means the resource was not found. 500 means the server hit an internal error. Headers carry extra details: cache rules, content type, cookies, compression, security policy, accepted encodings, and the server's preferred connection behavior.

Common HTTP Methods

HTTP, TCP, TLS, and DNS

When you type a URL, several layers cooperate before HTTP content appears. DNS first translates the domain name into an IP address. The browser then opens a connection to that address. With older HTTP/1.1 and most HTTP/2 deployments, that connection uses TCP. If the URL begins with https://, TLS negotiates encryption and verifies the site's certificate before any private HTTP data is exchanged.

Once the connection is ready, the browser sends HTTP requests. The server responds with the HTML page, and the browser parses it. If the HTML references CSS, JavaScript, images, fonts, analytics, or API calls, the browser makes more HTTP requests. A single page load can involve a few requests or hundreds. That is why web performance depends on more than raw download speed: each round trip, handshake, redirect, and blocked request adds time.

HTTP vs HTTPS

HTTP and HTTPS are not competing web formats. HTTPS is HTTP carried through TLS encryption. Plain HTTP sends request paths, headers, cookies, and content in readable form. Anyone on the same Wi-Fi network, ISP path, proxy, or compromised router could inspect or alter it. HTTPS protects that traffic from passive reading and active tampering, and it proves the server controls the certificate for the hostname you visited.

Modern websites should use HTTPS everywhere, including pages that do not handle passwords. Without HTTPS, attackers can inject ads or scripts, downgrade downloads, steal session cookies, or alter page content. Browsers also reserve many modern capabilities for secure contexts, including service workers, geolocation, camera access, and many advanced APIs.

HTTP/1.1, HTTP/2, and HTTP/3

HTTP semantics have stayed familiar across versions: clients still send methods, paths, headers, and bodies; servers still return status codes, headers, and bodies. The major differences are in how those messages move over the wire. HTTP/1.1 is text-based and handles limited parallelism per connection. Browsers worked around this by opening several TCP connections per site, but that adds handshake cost and can still leave resources waiting.

HTTP/2 keeps the same meaning but changes the framing. It uses a binary format, compresses repeated headers, and multiplexes many requests over one TCP connection. This reduces overhead and lets CSS, JavaScript, images, and API responses share a connection instead of waiting in separate queues. HTTP/3 moves HTTP onto QUIC over UDP. QUIC integrates encryption, connection setup, stream multiplexing, and packet-loss recovery in a way that avoids TCP-level head-of-line blocking. For users, HTTP/3 can make sites feel more resilient on lossy Wi-Fi and mobile networks.

Why HTTP Performance Can Feel Slow on Fast Internet

A speed test measures how much data can move once a path is flowing. Browsing often feels different because pages are made of dependencies. The browser may wait for DNS, redirects, TLS negotiation, HTML parsing, render-blocking CSS, JavaScript execution, third-party tags, and API responses. A 500 Mbps connection does not help much if the page spends 700 ms waiting on a slow origin server or a high-latency cellular path.

Latency and packet loss are especially visible in HTTP. A lost packet on a TCP connection can delay delivery of later data. A high ping time makes every handshake and API call take longer. Poor DNS resolution can slow the first request before the browser even reaches the site. For real troubleshooting, measure download speed, upload speed, latency, jitter, and packet loss together rather than relying on bandwidth alone.

Caching, Compression, and CDNs

HTTP includes a powerful caching model. Servers use headers such as Cache-Control, ETag, and Last-Modified to tell browsers and intermediary caches whether a resource can be reused. Good caching keeps repeat visits fast because the browser can avoid downloading unchanged files. Bad caching can do the opposite: users repeatedly download large assets that should have been stored locally.

Compression is another major HTTP performance feature. Text assets such as HTML, CSS, JavaScript, and JSON compress extremely well with gzip, Brotli, or Zstandard depending on server and browser support. CDNs add a geographic layer: instead of every visitor reaching the origin server, edge servers closer to the user serve cached content. This reduces latency and lowers origin load, especially for global websites.

Frequently Asked Questions

What does HTTP stand for?

HTTP stands for HyperText Transfer Protocol. It is the application layer protocol used by web browsers, web servers, APIs, crawlers, and many apps to request and transfer resources such as HTML pages, JSON, images, scripts, video segments, and files.

What is the difference between HTTP and HTTPS?

HTTP describes the request and response format. HTTPS is HTTP protected by TLS encryption. HTTPS prevents people on the network from reading or altering traffic, verifies the identity of the site through certificates, and is required by modern browsers for many features such as geolocation, service workers, HTTP/2 in most deployments, and secure login pages.

Is HTTP stateless?

Yes. Each HTTP request is independent by design. Servers use cookies, sessions, tokens, cache headers, and application databases to remember who you are and what you were doing across multiple requests.

What is the difference between HTTP/1.1, HTTP/2, and HTTP/3?

HTTP/1.1 sends requests over TCP connections and can suffer from head-of-line blocking. HTTP/2 keeps the same HTTP semantics but adds binary framing, multiplexing, and header compression over TCP. HTTP/3 moves HTTP semantics onto QUIC over UDP, reducing connection setup time and avoiding TCP-level head-of-line blocking when packet loss occurs.

Why does HTTP performance depend on latency?

A page often needs many request and response round trips: DNS lookup, TCP connection, TLS handshake, HTML download, and then additional requests for CSS, JavaScript, images, fonts, and API data. Higher latency makes every round trip slower, so web pages can feel sluggish even when raw download speed is high.