An HTTP response is the message a web server returns after receiving an HTTP request. It reports the outcome with a status code, describes the payload through header fields, and carries the requested data in an optional body. The response format is defined by RFC 9110 and is identical whether the reply comes from a static file, a REST API, or a redirect.
What Is an HTTP Response?
An HTTP response is the reply a server sends to a client after processing an HTTP request. It starts with a status line carrying the protocol version and a status code, followed by response headers and, for most methods, a body holding the requested resource. The status code is the first thing to read: it states whether the request worked before you inspect a single header or byte of content.
Every browser navigation, POST request, API call, and webhook delivery ends in a server response. When something breaks, the response is where the evidence lives.
HTTP Response Structure
An HTTP response has three parts in a fixed order: a status line, a block of header fields, and an optional message body. A blank line (CRLF) separates the headers from the body, which is how a parser knows where the metadata ends and the content begins.
HTTP/1.1 200 OK
Date: Tue, 22 Jul 2025 10:15:30 GMT
Server: nginx/1.25.3
Content-Type: application/json; charset=utf-8
Content-Length: 59
Cache-Control: max-age=60
Connection: keep-alive
{"id":1024,"name":"Jane Doe","role":"editor","active":true}The first line is the status line, the lines below it are response headers, and the JSON after the blank line is the body. The same three-part shape applies to every response, from a short 404 page to a multi-megabyte file download.
Status Line
The status line contains three tokens: the HTTP version, a three-digit status code, and a reason phrase. In the example above, HTTP/1.1 is the version, 200 is the status code, and OK is the reason phrase, a short human-readable label for the code.
The reason phrase is informational only; clients act on the numeric code, not the text. In HTTP/2 and HTTP/3 the textual status line is gone: the code travels in a :status pseudo-header and there is no reason phrase. A tool that prints 200 with no reason text is showing an HTTP/2 response, not a malformed one.
Message Body
The body carries the payload the client asked for: an HTML document, a JSON object, an image, or a file stream. Its format is declared by the Content-Type header and its length by Content-Length or chunked transfer encoding. Some responses have no body by design: 204 No Content and 304 Not Modified must not include one, and a reply to a HEAD request carries headers only.
When a body arrives compressed, Content-Encoding: gzip or br tells the client to decompress it before parsing. Reading the raw bytes without decoding them is a frequent source of "invalid JSON" errors that are gzip streams in disguise.
HTTP Response Status Codes
Every response carries a three-digit status code. The first digit sets the category, so you can classify any code, even one you have never seen, at a glance:
| Class | Range | Meaning |
|---|---|---|
1xx | 100–199 | Informational: the request was received and processing continues. |
2xx | 200–299 | Success: the request was received, understood, and accepted. |
3xx | 300–399 | Redirection: further action is needed to complete the request. |
4xx | 400–499 | Client error: the request is malformed or not allowed. |
5xx | 500–599 | Server error: the server failed to fulfill a valid request. |
The split between 4xx and 5xx decides where to look: a 4xx means the client sent something wrong, while a 5xx means the server broke on a request that may have been valid. Retrying a 4xx without changing the request is pointless; retrying some 5xx codes can succeed.
Common Status Codes
These codes cover the large majority of responses in day-to-day API and web work:
| Code | Reason | Typical cause |
|---|---|---|
200 | OK | Request succeeded; the body holds the resource. |
201 | Created | A resource was created; the Location header points to it. |
204 | No Content | Success with no body, common after a DELETE. |
301 | Moved Permanently | Permanent redirect; the client should update the URL. |
302 | Found | Temporary redirect to the URL in Location. |
304 | Not Modified | Cache validation hit; the client reuses its cached copy. |
400 | Bad Request | Malformed syntax, bad JSON, or invalid parameters. |
401 | Unauthorized | Missing or invalid authentication credentials. |
403 | Forbidden | Authenticated, but not allowed to access the resource. |
404 | Not Found | No resource matches the request target. |
422 | Unprocessable Content | Well-formed request, but the data fails validation. |
429 | Too Many Requests | Rate limit exceeded; check the Retry-After header. |
500 | Internal Server Error | An unhandled exception in the server application. |
502 | Bad Gateway | An upstream server returned an invalid response. |
503 | Service Unavailable | Server overloaded or down for maintenance. |
504 | Gateway Timeout | An upstream server did not respond in time. |
Response Headers
Response headers are the key-value fields between the status line and the body. They tell the client how to handle the reply: how to parse the body, whether to cache it, what cookies to store, and which cross-origin rules apply. A response with the right body but the wrong headers still fails.
| Header | Purpose |
|---|---|
Content-Type | Declares the body's media type, such as application/json or text/html. |
Content-Length | Size of the body in bytes, unless chunked encoding is used. |
Content-Encoding | Compression applied to the body, such as gzip or br. |
Cache-Control | How long, and whether, the client and proxies may cache the response. |
Set-Cookie | Stores a cookie in the client for use on later requests. |
Location | Target URL for a 3xx redirect or a 201 Created resource. |
Access-Control-Allow-Origin | Which origins may read the response under CORS. |
For the full field list, formatting rules, and request-side headers, see the HTTP headers reference. A single wrong value, a missing Access-Control-Allow-Origin or a stale Cache-Control, produces bugs that look like application errors but live entirely in the header block.
Common HTTP Response Mistakes
- 200 on failure: returning
200 OKwith an error message in the body. Clients treat the call as successful and never trigger retry or error handling. - Content-Type mismatch: sending JSON with
Content-Type: text/html, so the client refuses to parse it or a browser renders raw JSON. - Wrong redirect code: using
302where301is meant, so browsers and search engines keep hitting the old URL. - Missing CORS headers: the browser blocks a valid response because
Access-Control-Allow-Originis absent, and the console error points at the client instead of the server. - Content-Length mismatch: a declared length that does not match the body truncates the response or hangs the connection.
- Caching the uncacheable: a permissive
Cache-Controlon a personalized response leaks one user's data to another through a shared proxy.
Debugging HTTP Responses with HTTP Debugger
Log lines and framework error pages show a reconstruction of the response, not the exact bytes on the wire. To see the real status code, headers, and body an application received, capture the HTTP traffic itself. Browser DevTools do this for browser tabs, but desktop apps, background services, and CLI tools send responses that never reach them.
HTTP Debugger Pro captures HTTP and HTTPS responses from every process on Windows without a proxy: start a session and the grid lists each request with its status code, size, and timing. It decrypts HTTPS after you install its local root certificate, so response headers and bodies are readable instead of encrypted. The JSON, HTML, and header viewers parse a response into a readable tree, filtering by process name isolates one app, and the edit-and-resubmit feature replays a request after you change a single header. Download the 7-day trial and inspect a live response end to end.
HTTP Response FAQ
- What are the three parts of an HTTP response?
An HTTP response has three parts: a status line with the protocol version and status code, a block of response headers carrying metadata, and an optional message body holding the requested data. A blank line separates the headers from the body.
- What is the structure of an HTTP response?
The structure is a status line, then zero or more header fields, then a blank line, then an optional body. The status line reports the result, the headers describe how to handle the response, and the body carries the content.
- What do 2xx, 3xx, 4xx, and 5xx status codes mean?
2xx means success, 3xx means a redirect is needed, 4xx means the client sent an invalid request, and 5xx means the server failed on a valid request. The first digit of the code sets the category.
- What is the difference between a status code and a response header?
The status code is a single three-digit number in the status line that reports the overall result. Response headers are separate key-value fields that describe the body and control caching, cookies, and cross-origin access. A response has one status code and many headers.
- How can I see the raw HTTP response from a desktop app?
Browser DevTools only show browser responses. To capture the raw response from a desktop app, service, or CLI tool, use a system-wide HTTP capture tool such as HTTP Debugger, which records every process on Windows without a proxy and decrypts HTTPS once its local root certificate is trusted.