HTTP and HTTPS definition
HTTP (Hypertext Transfer Protocol) is the request and response protocol that browsers, apps and servers use to exchange web pages and API data. A client sends a request with a method, URL and headers, and the server returns a status code, headers and a body. HTTPS is HTTP sent over an encrypted TLS connection.
How does HTTP work?
Each HTTP exchange is a request followed by a response. The request names a method (what to do), a path (which resource), headers (metadata such as authentication, content type and caching rules) and an optional body. The server answers with a three-digit status code, its own headers and usually a body such as HTML, JSON or an image. HTTP is stateless: each request stands alone, so logins are carried in cookies or tokens sent every time.
Headers do much of HTTP's work. Content-Type says how to read the body, Authorization carries credentials, Cache-Control tells browsers and CDNs how long to keep a response, and Set-Cookie maintains sessions. Reading headers is often the fastest way to debug a failing API call or a page that will not update.
HTTP methods and status codes
Status codes fall into five classes: 1xx informational, 2xx success (200 OK, 201 Created), 3xx redirects (301 permanent, 304 not modified), 4xx client errors (400 bad request, 401 unauthenticated, 403 forbidden, 404 not found, 429 too many requests) and 5xx server errors (500, 502, 503). Our HTTP status codes reference explains each one. The main methods are:
- GET: read a resource; safe and cacheable
- POST: create a resource or trigger an action
- PUT: replace a resource entirely
- PATCH: update part of a resource
- DELETE: remove a resource
- OPTIONS: ask what is allowed, used by browsers for CORS preflight checks
HTTP vs HTTPS
Plain HTTP travels as readable text, so anyone on the network path, such as public Wi-Fi or a compromised router, can read passwords or alter pages. HTTPS wraps HTTP in TLS, which encrypts traffic, proves the server's identity with a certificate and detects tampering. Browsers label HTTP pages as not secure, features such as service workers and geolocation require HTTPS, and Google uses HTTPS as a ranking signal.
Free certificates from Let's Encrypt and automatic HTTPS on CDNs and hosting platforms have removed any cost argument for plain HTTP. Add an HSTS header so browsers refuse to fall back to HTTP for your domain in the future. Mixed content, where an HTTPS page loads scripts or images over HTTP, is blocked or flagged by browsers, so every asset URL must use HTTPS too.
HTTP/1.1, HTTP/2 and HTTP/3
HTTP/1.1 handles one request at a time per connection, so browsers opened several connections to load a page. HTTP/2, standardized in 2015, multiplexes many requests over one connection and compresses headers. HTTP/3, standardized in 2022 and now supported by all major browsers, runs over QUIC on UDP instead of TCP, avoiding head-of-line blocking when packets are lost and speeding up connections on mobile networks. Most CDNs enable HTTP/2 and HTTP/3 automatically, which can improve Core Web Vitals without code changes.
For APIs, the protocol version often matters less than connection handling: keep-alive connections, connection pooling in HTTP clients, compression and sensible timeouts usually do more for latency than a protocol upgrade alone. Measure before and after any change rather than assuming a newer version is faster for your traffic.