An HTTP response is the message a web server returns after receiving an HTTP request. It answers 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.
Server response and HTTP response name the same message. RFC 9110 calls it a response; "server response" names it from the sending side. The format is identical either way.
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}Read line by line, the same server response breaks down like this:
| Line | What it is |
|---|---|
HTTP/1.1 200 OK | Status line. Protocol version, status code, and reason phrase. The client branches on 200 before it reads anything else. |
Date: Tue, 22 Jul 2025 10:15:30 GMT | Header. When the server produced the response. Caches compute freshness from it. |
Server: nginx/1.25.3 | Header. Names the software that answered. Optional, and often stripped or faked in production. |
Content-Type: application/json; charset=utf-8 | Header. Declares how to parse the body. A wrong value here makes a client reject valid content. |
Content-Length: 59 | Header. Body size in bytes. The client reads exactly this many and stops. |
Cache-Control: max-age=60 | Header. Lets the client and any shared proxy reuse the body for 60 seconds. |
Connection: keep-alive | Header. Keeps the TCP connection open for the next request. HTTP/1.1 only; HTTP/2 has no such field. |
| (blank line) | Separator. A bare CRLF. Everything before it is metadata, everything after it is body. |
{"id":1024, …} | Body. The payload the request asked for, in the format Content-Type declared. |
Every response follows this layout, from a 404 error page to a multi-megabyte file download. What differs between HTTP responses is the code in the status line, which header fields appear, and whether a body follows at all.
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 explanation of the outcome.
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.
Error Response Example
A failed request returns the same three parts. Only the status code and the contents change:
HTTP/1.1 404 Not Found
Date: Tue, 22 Jul 2025 10:15:33 GMT
Server: nginx/1.25.3
Content-Type: application/problem+json; charset=utf-8
Content-Length: 152
Cache-Control: no-store
{"type":"https://api.example.com/errors/not-found","title":"Not Found","status":404,"detail":"No user exists with id 9931","instance":"/api/users/9931"}
Three details in this server response carry the diagnosis. 404 in the status line is the machine-readable verdict, and it is what retry logic and monitoring act on. application/problem+json is the standard media type for API error bodies, defined in RFC 9457, so a client can show detail to the user without parsing a vendor-specific error shape. Cache-Control: no-store keeps the failure out of shared caches, so one user's 404 is not replayed to the next.
The status field inside the body repeats the code for logging convenience. It is not the source of truth: clients read the status line.
Redirect Response Example
A redirect answer is usually metadata alone. Here the whole reply is the status code and one header:
HTTP/1.1 301 Moved Permanently
Date: Tue, 22 Jul 2025 10:15:35 GMT
Server: nginx/1.25.3
Location: https://api.example.com/v2/users/1024
Content-Length: 0
Connection: keep-alive
Location holds the URL to follow, and Content-Length: 0 states there is nothing to read after the blank line. The code decides what the client does next. 301 declares the move permanent, so browsers and search engines replace the old URL; 302 declares it temporary and keeps the old one. Both are historically allowed to rewrite a POST into a GET while following the redirect, which drops the request body without an error. 307 and 308 preserve the method and body instead.
HTTP Response Status Codes
Every server 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 1xx100–199 Informational: the request was received and processing continues. 2xx200–299 Success: the request was received, understood, and accepted. 3xx300–399 Redirection: further action is needed to complete the request. 4xx400–499 Client error: the request is malformed or not allowed. 5xx500–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.
A 1xx code is interim rather than final. 100 Continue tells a client that sent Expect: 100-continue to go ahead and upload the body, and 101 Switching Protocols completes a WebSocket upgrade. Neither ends the exchange, so neither shows up as the outcome of a finished request.
Common Status Codes
These codes cover the large majority of HTTP responses in day-to-day API and web work:
Code Reason Typical cause 200OK Request succeeded; the body holds the resource. 201Created A resource was created; the Location header points to it. 202Accepted Queued for processing that has not finished; the result is fetched later. 204No Content Success with no body, common after a DELETE. 206Partial Content Answer to a Range request, used by video seeking and resumable downloads. 301Moved Permanently Permanent redirect; the client should update the URL. 302Found Temporary redirect to the URL in Location. 304Not Modified Cache validation hit; the client reuses its cached copy. 307Temporary Redirect Temporary redirect that keeps the original method and body. 308Permanent Redirect Permanent redirect that keeps the original method and body. 400Bad Request Malformed syntax, bad JSON, or invalid parameters. 401Unauthorized Missing or invalid authentication credentials. 403Forbidden Authenticated, but not allowed to access the resource. 404Not Found No resource matches the request target. 405Method Not Allowed The target exists but rejects this method; Allow lists the ones it takes. 409Conflict The request clashes with current state, such as a duplicate key or a stale version. 410Gone The resource was removed deliberately and is not coming back. 415Unsupported Media Type The server refuses the body's Content-Type. 422Unprocessable Content Well-formed request, but the data fails validation. 429Too Many Requests Rate limit exceeded; check the Retry-After header. 500Internal Server Error An unhandled exception in the server application. 502Bad Gateway An upstream server returned an invalid response. 503Service Unavailable Server overloaded or down for maintenance. 504Gateway 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 and the wrong headers still fails.
The fields that carry most of that work:
Header Purpose Content-TypeDeclares the body's media type, such as application/json or text/html. Content-LengthSize of the body in bytes, unless chunked encoding is used. Transfer-Encodingchunked when the size is not known up front; the body arrives in sized chunks.Content-EncodingCompression applied to the body, such as gzip or br. Cache-ControlHow long, and whether, the client and proxies may cache the response. ETagVersion identifier for the body. A later request sends it back to ask for 304. VaryWhich request headers change the response, so a shared cache keeps the variants apart. Set-CookieStores a cookie in the client for use on later requests. LocationTarget URL for a 3xx redirect or a 201 Created resource. Retry-AfterHow long to wait before trying again, sent with 429 and 503. WWW-AuthenticateThe authentication scheme the server expects, sent with 401. Access-Control-Allow-OriginWhich origins may read the response under CORS.
Field names are case-insensitive and their order carries no meaning, with one exception worth knowing: repeated fields such as Set-Cookie form a list, and code that keeps only the last one silently drops cookies. The full field list, the syntax rules, and the request-side headers are on the HTTP headers reference.
Which Header to Read When a Response Looks Wrong
Bugs that present as application errors are frequently one header field in the server response. The symptom usually names the field:
Symptom Read first The browser blocks a response that arrived intact Access-Control-Allow-Origin, and the rest of the CORS blockA valid JSON body fails to parse Content-Type, then Content-EncodingThe download truncates or the connection hangs Content-Length against Transfer-EncodingA deployment does not reach users Cache-Control and ETagA session drops right after login Set-Cookie attributes: Domain, Path, Secure, SameSiteThe client loops between two URLs Location on each hopOne user is served another user's data Cache-Control and VaryRequests fail with 429 at unpredictable times Retry-After
Each of these needs the headers the client received, not the headers the application meant to send. A gateway, CDN, or framework middleware can add, drop, or rewrite fields between the two.
Common HTTP Response Mistakes
- 200 on failure: returning
200 OK with 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
302 where 301 is meant, so browsers and search engines keep hitting the old URL. - Missing CORS headers:
Access-Control-Allow-Origin is absent, so the browser blocks a valid response 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-Control on 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 part of an HTTP response provides the HTTP version, status code, and a brief explanation of the response's outcome?
The status line. It is the first line of every HTTP response and holds three tokens in order: the protocol version (HTTP/1.1), the three-digit status code (404), and the reason phrase (Not Found), which is the brief human-readable explanation of the outcome. Everything below the status line is headers and body. In HTTP/2 and HTTP/3 the same information arrives as a :status pseudo-header with no reason phrase.
- What is the structure of an HTTP response?
The structure is fixed: a status line, then zero or more header fields one per line, then an empty line, then an optional body. The empty line is required even when nothing follows it, which is why a 204 No Content response still ends with a bare CRLF.
- What data structure do HTTP responses typically use for their return?
JSON, carried in the message body. The response message itself is text: a status line, then header fields as Name: value pairs, then a blank line, then the body. The body's own structure is declared by Content-Type, with application/json for APIs, text/html for pages, and application/octet-stream for binary downloads. JSON is the default return format for REST and GraphQL; XML persists in SOAP and older enterprise APIs.
- 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.