What is the difference between an HTTP request header and a response header?
Quick answer
A request header travels from the client to the server as part of an HTTP request. A response header travels from the server to the client as part of the HTTP response. Both carry metadata: request headers can describe the requested resource or client, while response headers can add information about the response, including its format. Direction depends on which message contains the header; some fields can be used in more than one context. [S1] [S2]
The question, the details, the next step.
I see headers on both sides of an HTTP exchange. What makes one a request header and the other a response header?
It is the message containing the header that determines its direction. A request header is sent with the client's request to the server; a response header is sent with the server's response back to the client. Headers carry additional information about a message. For example, request headers may give context about the requested resource or client, and response headers may describe the response or the format returned. [S1] [S2]
A useful mental model is: request headers accompany the question being sent; response headers accompany the answer coming back. The word “header” by itself does not tell you which direction it travels.
Could you label a simple exchange so I can tell where each header goes?
Here is a simplified, illustrative exchange. The labels explain direction; they are not part of the HTTP message.
Client -> Server: request
GET /guide HTTP/1.1
Host: example.test
Server -> Client: response
HTTP/1.1 200 OK
Content-Type: text/html
[response body]Host is shown in the request, so it travels client-to-server. Content-Type is shown in the response, so it travels server-to-client and gives information about the returned format. These example placements illustrate the distinction; they are not a complete exchange or a guarantee about what a particular server will return. Request headers can provide context or affect how a server treats a request; response headers can provide information such as the format actually returned. [S1]
So is Content-Type always a response header, and is Host always a request header?
Do not classify a field solely by its name. Some header fields can be used in more than one context, so an example should not imply that every field is exclusive to requests or responses. [S2] In the exchange above, the labels tell you how those particular instances are being used.
When inspecting a real message, first identify its boundary: is it the message the client sends, or the one the server sends back? Then read the header lines within that message. This is more reliable than memorizing a fixed list of “request-only” and “response-only” names.
What should I check when a tool shows me a header and I am not sure which side it belongs to?
Use this quick sequence:
- Find the request and response sections in the tool or log.
- Check which section contains the header; that establishes its direction.
- Note the sender and receiver: client to server for the request, server to client for the response.
- Read the header’s value in that message’s context rather than assuming the name dictates direction.
- If the display does not show message boundaries, consult the tool’s documentation or use a view that separates the request from the response.
The general roles of HTTP headers do not determine how a particular browser, proxy, or debugging tool displays them. Check the tool’s display separately if the message boundaries are unclear.
A practical checklist
Locate the message boundary before classifying a header.
For a request, label direction client to server; for a response, label server to client.
Record the header name and value under the message where it appears.
Treat examples as illustrative; do not assume every field is exclusive to one direction.
If a tool hides the request/response split, check its documentation or use a clearer view.
A few more useful answers
Do request and response headers both carry metadata?
Yes. Both pass additional information with an HTTP message; the information’s role depends on whether it accompanies the request or the response. [S2]
Can the same header field appear in both directions?
Some fields can be used in more than one context. Check the message containing the field instead of inferring direction from its name. [S2]
Does a response header describe the response body?
It can provide information about the response, including the format actually returned. The example’s Content-Type illustrates that use. [S1]
Sources
References used for this guide.
- [S1] HTTP messages — MDN developer.mozilla.org · Checked
- [S2] HTTP headers — MDN developer.mozilla.org · Checked