HTTP works through a request-and-response system that allows web browsers and other clients to communicate with web servers. When you open a webpage, your browser sends an HTTP request identifying the resource it wants. The server processes that request and returns an HTTP response containing the requested content, a status code, and information about how the response should be handled.
This exchange forms the foundation of the World Wide Web. HTTP defines the meaning and structure of communication, while underlying networking protocols transport the information between devices.
HTTP is used for more than loading webpages. It also allows applications to submit forms, retrieve data, upload files, and communicate with online services.
What Is HTTP?
HTTP stands for Hypertext Transfer Protocol.
It is an application-layer protocol that defines how clients request resources and how servers respond to those requests.
According to the MDN HTTP overview, HTTP uses a client-server communication model in which clients initiate requests and servers return responses.
A client is usually a web browser, but it can also be a mobile application, command-line tool, or another software program.
A server is a system capable of receiving HTTP requests and producing appropriate responses.
The resources exchanged through HTTP can include:
- HTML documents that define webpage content.
- CSS stylesheets that control visual appearance.
- JavaScript files that enable interactive behavior.
- Images, fonts, videos, and downloadable documents.
- Structured data such as JSON used by web applications.
- Information submitted through forms or application interfaces.
Although HTTP originally developed around hypertext documents, its capabilities now support many different kinds of online communication.
HTTP Is a Protocol, Not a Physical Connection
HTTP does not determine how electrical signals, radio waves, or optical pulses travel through a network.
Those responsibilities belong to other networking technologies.
Instead, HTTP defines what a request means, what a response means, and how the two participants exchange information.
For example, HTTP specifies that a GET request asks for a representation of a resource.
It also defines status codes such as 200 OK and 404 Not Found.
The HTTP Semantics specification, RFC 9110, defines these shared meanings independently of the specific HTTP wire format.
This separation allows different versions of HTTP to communicate using different transport mechanisms while preserving the same basic application behavior.
How Does HTTP Work Step by Step?
Imagine opening this example webpage:
https://www.example.com/guide
A typical browser navigation involves several stages.
Some stages can be skipped or shortened when the browser already has cached information or an existing connection.
Step 1: The Browser Interprets the URL
When you enter a website address, the web browser identifies the resource you want.
The address is called a Uniform Resource Locator, or URL.
For example:
https://www.example.com/guide
It contains several components:
| Component | Example | Purpose |
|---|---|---|
| Scheme | https | Specifies secure HTTP communication |
| Hostname | www.example.com | Identifies the requested host |
| Path | /guide | Identifies the requested resource |
A URL can also include a port, query parameters, and a fragment identifier.
The browser uses this information to determine where the request should go and which resource it should request.
Step 2: DNS Helps Locate the Destination
Before contacting a remote service, the browser generally needs its network address.
The Domain Name System (DNS) helps resolve the hostname into suitable addressing information.
For example, DNS may return an IPv4 or IPv6 address associated with the requested service.
The result can come from cached information or from queries performed through a recursive DNS resolver.
Once the browser has the required information, it can attempt to establish communication with the destination.
The DNS lookup is not itself an HTTP request.
DNS and HTTP are different protocols that perform different functions.
DNS helps locate the service. HTTP defines how the client requests resources from it.
Step 3: The Browser Establishes Communication
HTTP requires an underlying transport capable of carrying requests and responses.
The details depend on the HTTP version.
For HTTP/1.1 and HTTP/2, communication commonly uses TCP.
TCP provides reliable, ordered delivery of data between endpoints.
When these HTTP versions use HTTPS, TLS protects the connection through encryption and authentication.
HTTP/3 operates differently.
It uses QUIC, a transport protocol built on UDP that provides reliable streams and integrates TLS-based security.
The HTTP/3 specification, RFC 9114, defines how HTTP requests and responses are carried over QUIC.
The important distinction is that HTTP describes application communication, while TCP or QUIC handles essential transport responsibilities.
A browser may also reuse an existing connection rather than establishing a new one for every request.
Step 4: The Browser Sends an HTTP Request
Once communication is available, the browser sends a request.
For the example webpage, a simplified HTTP/1.1 request looks like this:
GET /guide HTTP/1.1
Host: www.example.com
Accept: text/html
The request contains several meaningful parts.
GET is the HTTP method. It asks the server to provide a representation of the requested resource.
/guide identifies the resource being requested.
HTTP/1.1 identifies the protocol version used in this illustrative message format.
Host identifies the requested hostname.
Accept tells the server which response media types the client can accept.
An actual browser request can contain additional headers, depending on the circumstances.
HTTP/2 and HTTP/3 represent requests differently on the wire, but the meaning of the request remains comparable.
Step 5: The Web Server Processes the Request
The request reaches the server or intermediary responsible for handling it.
A web server examines the request and determines how to respond.
If the resource is a static HTML document, the server may retrieve an existing file.
If the resource is dynamic, the server may run application code, access a database, or communicate with another service.
For example, an online store receiving a request for a product page might retrieve the product’s description, price, and availability before preparing the response.
The server also evaluates relevant conditions such as authentication, permissions, cache validation, and whether the requested resource exists.
HTTP defines the communication rules, but it does not require every server to generate content using the same internal architecture.
Step 6: The Server Returns an HTTP Response
After processing the request, the server sends a response.
A simplified HTTP/1.1 response might begin with:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
The response body could then contain:
<h1>How HTTP Works</h1>
In this illustrative response, 200 OK indicates that the request succeeded.
The Content-Type header identifies the returned content as HTML using UTF-8 character encoding.
The response body contains the resource representation.
Not every HTTP response has a body.
Some responses carry only status and header information, while others redirect the client or indicate that an existing cached representation remains usable.
Step 7: The Browser Processes the Response
The browser receives the response and interprets it according to the HTTP status, headers, and content.
If the response contains HTML, the browser can parse it and begin constructing the webpage.
It may discover additional resources, including stylesheets, scripts, images, and fonts.
Each resource can require another HTTP request.
For example, one webpage might involve separate requests for:
/guide/styles/main.css/scripts/app.js/images/diagram.webp
The browser can process and download some resources concurrently.
It then interprets the retrieved content to display the page.
This rendering process is separate from HTTP itself.
The broader relationship between server responses, frontend resources, and backend systems is explained in How Does a Website Work?.
What Is an HTTP Request?
An HTTP request is a message sent by a client to ask a server to perform an operation involving a resource.
For HTTP/1.1, a typical request contains a request line, header fields, a blank line, and an optional message body.
| Request Component | Purpose | Example |
|---|---|---|
| Method | Specifies the requested operation | GET |
| Request target | Identifies the requested resource | /products |
| Protocol version | Identifies the HTTP message version | HTTP/1.1 |
| Headers | Provide additional request information | Accept: application/json |
| Body | Carries optional request content | JSON or form data |
The body is not required for every request.
A GET request commonly has no request body.
A POST request often includes data that the server needs to process.
What Are HTTP Methods?
HTTP methods describe the intended operation.
The most common methods include:
| Method | Main Purpose |
|---|---|
| GET | Retrieve a representation of a resource |
| POST | Submit data for processing |
| PUT | Create or replace the state of a target resource |
| PATCH | Apply partial modifications to a resource |
| DELETE | Request removal of a resource’s association |
| HEAD | Retrieve response metadata without the response content |
| OPTIONS | Request information about communication options |
MDN’s HTTP request methods reference describes the meaning and expected behavior of these methods.
Consider an online store.
When someone opens a product page, the browser may send a GET request.
When the customer submits an order, the application may send a POST request containing the relevant order information.
The server interprets the method and request data to determine which operation to perform.
Are GET and POST Interchangeable?
No.
HTTP assigns different semantics to these methods.
GET is defined as a safe method, meaning the client requests a read-only operation rather than a change to the target resource’s state.
POST allows the server to process submitted data, which may cause state changes.
The server still needs to implement these semantics correctly.
For example, an application should not perform an irreversible purchase merely because a user opens a URL with a GET request.
HTTP also defines the concept of idempotence.
A method is idempotent when making the same request multiple times has the same intended effect on server state as making it once.
GET, PUT, and DELETE are defined as idempotent methods, although repeated requests may still produce different response messages or incidental effects such as logging.
POST is not generally idempotent by definition.
These distinctions matter when clients retry requests after interruptions.
What Is an HTTP Response?
An HTTP response communicates the result of a request.
It usually contains a status code, relevant headers, and optionally a body.
The status code tells the client what happened at the HTTP level.
The headers provide information about the response or how it should be processed.
The body contains the representation or other data, when applicable.
For example, a server might return an HTML page with a 200 OK response.
If the requested page has moved, it might return a redirect.
If the resource does not exist, it might return 404 Not Found.
A successful HTTP exchange does not necessarily mean that every part of the website’s application is functioning correctly.
A server can return 200 OK while the webpage contains a JavaScript error or displays incorrect information.
HTTP status codes describe the outcome of the HTTP request as reported by the responding server.
How Do HTTP Status Codes Work?
HTTP status codes are three-digit numbers grouped into five classes.
| Status Range | Category | Meaning |
|---|---|---|
| 1xx | Informational | Request processing or protocol information |
| 2xx | Successful | The request was successfully handled |
| 3xx | Redirection | Further action or reuse of stored information may be appropriate |
| 4xx | Client Error | The request cannot be completed under the relevant conditions |
| 5xx | Server Error | The server failed to fulfill a request |
According to the MDN status code reference, each status code communicates a specific result to the client.
Some frequently encountered codes include:
| Code | Meaning | Typical Situation |
|---|---|---|
| 200 OK | Request succeeded | A webpage is returned |
| 201 Created | A new resource was created | An API creates a record |
| 204 No Content | Request succeeded without response content | An update completes without a response body |
| 301 Moved Permanently | Resource has a permanent new location | An old URL redirects |
| 302 Found | Resource temporarily uses another location | A temporary redirect |
| 304 Not Modified | Cached representation can be reused | Conditional cache validation |
| 400 Bad Request | Request is invalid or cannot be processed | Malformed request data |
| 401 Unauthorized | Authentication is required or invalid | Missing login credentials |
| 403 Forbidden | Server refuses the request | Insufficient permissions |
| 404 Not Found | Requested resource was not found | Missing webpage |
| 429 Too Many Requests | Request rate is being limited | API rate limit reached |
| 500 Internal Server Error | Unspecified server failure | Backend error |
| 503 Service Unavailable | Service cannot currently handle the request | Overload or maintenance |
The distinction between 401 and 403 is particularly important.
A 401 Unauthorized response concerns authentication credentials, despite the potentially confusing name.
A 403 Forbidden response means the server understands the request but refuses to fulfill it.
How Do HTTP Redirects Work?
A redirect tells the client to use another location for a resource or subsequent action.
The server commonly provides the new location through a Location response header.
For example:
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page
The browser can then make another request to the new address.
HTTP defines several redirect codes with different semantics.
For example, 307 Temporary Redirect and 308 Permanent Redirect preserve the request method under the defined redirection behavior, unlike certain historical method-changing behavior associated with 301 and 302.
The MDN HTTP redirection guide explains these differences.
Redirects are useful when website addresses change, but unnecessary redirect chains can increase the number of requests required to reach a resource.
What Are HTTP Headers?
HTTP headers are fields that carry additional information about a request or response.
They allow clients, servers, and intermediaries to communicate details beyond the method, resource identifier, and status code.
Some common headers include:
| Header | Main Function |
|---|---|
Host | Identifies the requested host in HTTP/1.1 |
Content-Type | Describes the media type of the content |
Accept | Indicates acceptable response media types |
Accept-Encoding | Indicates supported content codings |
Content-Encoding | Identifies content encoding such as gzip or Brotli |
Cache-Control | Communicates caching instructions |
ETag | Provides a validator for a resource representation |
Authorization | Carries authentication credentials |
Cookie | Sends applicable stored cookies |
Set-Cookie | Instructs the client to store a cookie |
Location | Identifies a redirect destination or other location |
Headers are an important reason HTTP is extensible.
New features can be introduced through fields understood by compatible clients and servers without replacing the entire protocol.
How Does Content Negotiation Work?
HTTP can help clients and servers select an appropriate representation of a resource.
For example, a browser might indicate that it accepts certain image formats or compressed content.
The server can select a suitable response representation based on the request and its available capabilities.
This process is called content negotiation.
An Accept-Language header can also communicate language preferences.
However, the server is not universally required to produce every representation requested by a client.
The MDN content negotiation guide explains how request headers can influence selected response content.
Why Is HTTP Called Stateless?
HTTP is described as a stateless protocol because the meaning of an individual request does not inherently depend on the server remembering an earlier request.
For example, imagine these separate requests:
GET /products
GET /cart
HTTP does not automatically define which customer owns the shopping cart simply because the requests arrive over the same network connection.
The application needs additional information to associate requests with a user or session.
How Do Websites Remember Users?
One common solution is HTTP cookies.
When you sign in, the server may return a Set-Cookie header.
A simplified example is:
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax; Path=/
This is an illustrative cookie value, not a real authentication credential.
The browser can store the cookie and include it in later requests when the cookie’s scope and applicable policies permit.
The server uses the session information to recognize the ongoing interaction.
MDN’s HTTP cookies guide explains how cookies support sessions and how their attributes affect storage and transmission.
The stateless nature of HTTP does not mean websites cannot maintain login sessions, shopping carts, or personalized experiences.
It means the application must implement the relevant state-management mechanisms.
Does a Persistent Connection Make HTTP Stateful?
No.
A persistent TCP connection allows multiple requests and responses to use the same underlying connection.
But connection reuse is different from remembering application state.
A server can process multiple requests on one connection without treating them as belonging to one authenticated user unless the application provides appropriate session context.
This distinction separates transport behavior from HTTP application semantics.
How Does HTTP Caching Work?
HTTP caching allows previously obtained responses to be reused when the applicable caching rules permit.
This can reduce network traffic, improve response times, and lower the load on servers.
Caches may exist in browsers, intermediary proxies, and distributed delivery systems.
For example, a browser might download a stylesheet when someone visits a website.
If the same stylesheet is needed on another page, the browser may reuse its cached copy rather than downloading it again.
How Does Cache-Control Work?
A server can send a header such as:
Cache-Control: public, max-age=3600
This example permits shared caching under the applicable HTTP rules and indicates a freshness lifetime of one hour.
A cache can reuse the stored response while it remains fresh, subject to the relevant conditions.
Other directives include:
- private: Restricts storage of the response to private caches.
- no-store: Instructs caches not to store the response.
- no-cache: Requires successful validation before a stored response is reused.
- s-maxage: Specifies a freshness lifetime for shared caches.
The name no-cache can be misleading.
It does not necessarily prohibit storing the response. It means the stored response must be validated before reuse.
The MDN HTTP caching guide explains how freshness and validation determine whether a response can be reused.
What Happens When a Cached Resource Changes?
Suppose a browser previously downloaded a stylesheet.
The server provided an identifier called an ETag:
ETag: "style-version-7"
Later, the browser may send a conditional request:
If-None-Match: "style-version-7"
If the stored representation is still current, the server can respond:
304 Not Modified
The browser can then reuse the existing content according to the updated cache information.
If the representation has changed, the server can return the newer version.
This process is called cache validation.
It can avoid downloading the same content unnecessarily while still allowing websites to update resources.
How Do CDNs and Proxy Servers Use HTTP?
A browser does not always communicate directly with the origin server responsible for a website.
HTTP requests may pass through intermediary infrastructure.
A proxy server receives requests and forwards them according to its configuration.
A reverse proxy can sit in front of application servers and handle tasks such as routing, caching, load balancing, or security filtering.
A content delivery network (CDN) uses distributed infrastructure to deliver content efficiently.
For example, when a browser requests an image:
- The HTTP request reaches a CDN edge server.
- The CDN checks whether a valid cached response is available.
- If the response is cached, the CDN can return it directly.
- Otherwise, the CDN may request the resource from an upstream cache or origin server.
HTTP headers help determine whether and how responses can be cached.
The CDN therefore uses HTTP semantics to deliver the same types of resources that a conventional web server provides.
However, it changes which infrastructure handles the request.
This is one reason HTTP supports a scalable web architecture rather than requiring every browser to communicate directly with one physical server.
What Is the Difference Between HTTP and HTTPS?
HTTP defines the semantics of requests and responses.
HTTPS protects those communications using TLS.
| Feature | HTTP | HTTPS |
|---|---|---|
| Core communication model | Request and response | Request and response |
| Transport security | Not provided inherently | TLS protection |
| Confidentiality | No inherent encryption | Protected between TLS endpoints |
| Integrity protection | No inherent cryptographic protection | Provided by TLS |
| Server authentication | Not provided by HTTP alone | TLS certificate authentication |
| URL scheme | http:// | https:// |
| Conventional default port | 80 | 443 |
HTTPS protects HTTP message contents from ordinary network observers on the encrypted connection.
It also helps detect unauthorized modifications to the protected data.
However, HTTPS does not guarantee that a website is legitimate or prevent the destination from accessing the information that users submit.
The important distinction is that HTTPS does not replace HTTP’s request-and-response model.
It adds protection to the communication carrying those requests and responses.
How Does HTTP/1.1 Work?
HTTP/1.1 uses a textual message format consisting of request or status lines, headers, and optional content.
It commonly operates over TCP.
One of its important features is support for persistent connections.
A client can send multiple requests over the same TCP connection instead of establishing an entirely new connection for every resource.
This reduces repeated connection-establishment overhead.
However, HTTP/1.1 does not provide the multiplexed stream architecture of HTTP/2.
Responses on one HTTP/1.1 connection can create ordering constraints, and browsers often use multiple connections to handle resources concurrently.
The HTTP/1.1 specification, RFC 9112, defines the message syntax and connection handling for this version.
HTTP/1.1 remains important because its readable request and response format is useful for understanding the fundamentals of HTTP.
How Does HTTP/2 Work?
HTTP/2 preserves the essential semantics of HTTP while changing how messages are represented and transmitted.
Instead of using the same textual wire format as HTTP/1.1, HTTP/2 carries information in binary frames.
It also supports multiplexing.
What Is Multiplexing?
Multiplexing allows multiple independent HTTP request-response exchanges to share one connection.
For example, a browser might request:
- An HTML document.
- A CSS stylesheet.
- A JavaScript file.
- Several images.
With HTTP/2, these exchanges can use different streams on the same connection.
Their frames can be interleaved rather than forcing one complete response to finish before another begins.
HTTP/2 also provides header compression to reduce repeated header information.
The HTTP/2 specification, RFC 9113, defines the framing and stream mechanisms.
However, because HTTP/2 commonly runs over TCP, packet loss affecting the TCP connection can still delay delivery across its streams.
Multiplexing improves how HTTP exchanges share a connection, but it does not remove all transport-layer limitations.
How Does HTTP/3 Work?
HTTP/3 keeps the familiar HTTP request-and-response semantics but uses QUIC as its transport protocol.
QUIC operates over UDP and provides reliable streams, congestion control, and integrated TLS-based security.
One of its important characteristics is that separate QUIC streams can make progress independently when packet loss affects another stream.
This helps avoid the cross-stream transport head-of-line blocking associated with using HTTP/2 over a single TCP connection.
According to RFC 9114, HTTP/3 maps HTTP semantics onto QUIC streams.
HTTP/3 also supports mechanisms for efficient connection establishment and transport management.
However, HTTP/3 is not automatically faster than HTTP/2 under every network condition.
Performance depends on factors such as packet loss, latency, server support, network configuration, and implementation quality.
HTTP/1.1 vs. HTTP/2 vs. HTTP/3
| Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Common transport | TCP | TCP | QUIC over UDP |
| Message framing | Text-based | Binary frames | Binary frames over QUIC |
| Multiplexing | No equivalent stream multiplexing | Yes | Yes |
| Header compression | No HTTP/2-style compression | HPACK | QPACK |
| Stream handling | HTTP/1.1 ordering constraints | Multiple streams over TCP | Independent QUIC streams |
| TLS protection | Optional through HTTPS | Commonly used through HTTPS | Integrated through QUIC |
The versions differ mainly in how they transport and organize communication.
They do not fundamentally change the meaning of common HTTP operations such as GET, POST, or the 404 Not Found status.
How Does HTTP Support APIs and Web Applications?
HTTP is used far beyond traditional webpages.
Many mobile applications and web services exchange structured data through HTTP-based APIs.
An API, or Application Programming Interface, defines how software components can request information or operations from another service.
For example, a weather application might send:
GET /api/weather?city=Boston
The server could return JSON data such as:
{"city":"Boston","temperature_c":18}
This example is hypothetical.
The response body is JSON rather than HTML, but the exchange still uses HTTP.
Other API operations may use POST, PUT, PATCH, or DELETE.
The application determines what each resource and operation means, while HTTP supplies common communication methods, headers, status codes, and transport-independent semantics.
What Is CORS?
Web browsers enforce security restrictions on how scripts from one origin can access resources from another origin.
Cross-Origin Resource Sharing (CORS) uses HTTP headers to let servers indicate which cross-origin interactions are permitted.
For some requests, the browser sends a preliminary OPTIONS request, called a preflight request, before sending the actual cross-origin request.
The server can respond with headers describing its cross-origin permissions.
MDN’s CORS guide explains how browsers enforce these rules.
CORS is primarily a browser-enforced access mechanism. It is not a replacement for authentication or authorization on the server.
Why Can an HTTP Request Fail?
An HTTP operation can fail at different stages.
The browser may be unable to contact the server at all.
For example, DNS resolution could fail, a network connection might time out, or a TLS handshake could fail.
These problems may prevent the client from receiving any HTTP response.
Other failures occur after the request reaches an HTTP server.
For example:
404 Not Foundindicates that the requested resource was not found.403 Forbiddenindicates that the server refuses to fulfill the request.429 Too Many Requestscan indicate rate limiting.500 Internal Server Errorindicates a server-side processing failure.503 Service Unavailablecan indicate temporary overload or maintenance.
A browser displaying an error message does not necessarily mean that the server returned an HTTP error status.
Distinguishing connection failures from HTTP responses is useful when investigating website problems.
Does HTTP Download an Entire Website at Once?
Usually not.
HTTP allows clients to request individual resources.
When you open a webpage, the browser commonly retrieves an initial HTML document and then requests additional resources as needed.
Some resources may be loaded immediately.
Others may be requested later when the visitor scrolls, navigates, or interacts with the application.
For example, a browser may delay loading an image located far below the visible part of the page.
JavaScript can also make additional HTTP requests without navigating to a new document.
This allows applications to update selected content dynamically.
HTTP therefore supports both complete webpage navigations and smaller exchanges of information during ongoing user interactions.
HTTP Is the Web’s Communication Language
HTTP works by defining a common language for requests and responses between clients, servers, and intermediaries.
A client identifies a resource and an intended operation. The server evaluates the request and returns a response containing a status, metadata, and any applicable content.
HTTP methods describe operations, status codes communicate outcomes, headers provide additional instructions, and caching can reduce unnecessary transfers.
Newer versions such as HTTP/2 and HTTP/3 improve how requests and responses are transported without replacing the underlying communication model.
The essential principle remains unchanged: HTTP tells clients and servers what information is being requested, how to interpret the response, and how to coordinate the exchange of web resources.