HTTP Response Formatter
Format a textual HTTP response capture, preserve repeated fields, inspect cookies and body media types, and surface framing or status inconsistencies without replaying the original request.
Best for HTTP/1.x captures and human-readable HTTP/2/3 summaries from DevTools, logs, proxies and API clients. HTTP/2 and HTTP/3 do not use this textual format on the wire.
Parsed status, headers, cookies, body formatting and framing diagnostics will appear here.
Read the Status Code First; Treat the Reason Phrase as Commentary
In an HTTP/1.1 line such as HTTP/1.1 404 Not Found, the three-digit status code carries the protocol meaning. The reason phrase is optional human text and can be changed or omitted by intermediaries.
The formatter displays the phrase because it helps humans read a capture, but classifies the response from the numeric code rather than from words like “OK” or “Not Found.”
JSON-Looking Text Is Not Automatically Valid JSON
A response can advertise application/json and still contain a truncated object, HTML error page or malformed JSON. Earlier formatters often attempted pretty-printing and then still labelled a failed body as JSON.
This version keeps the original body and labels it invalid JSON when the media type claims JSON but parsing fails. That distinction matters when debugging API gateways that return non-JSON errors behind a JSON-oriented endpoint.
Repeated Response Fields Are Part of the Evidence
HTTP field names compare case-insensitively, but a response can contain repeated field lines. Some fields can be combined according to their own semantics; Set-Cookie is the famous exception that must remain separate.
This formatter never reduces the header block to a single-value object. That keeps duplicate Content-Length, Content-Type, Location and cookie lines visible when they are exactly the issue you need to investigate.
Content-Length and the Pasted Body Size Answer Different Questions
Content-Length is message framing metadata. The size shown here is the UTF-8 size of the text currently in your browser textarea. DevTools or an HTTP client can already have decompressed content, decoded transfer framing, normalized line endings or converted bytes into Unicode text before you copied it.
A mismatch is therefore a diagnostic clue, not an automatic verdict that the origin server sent an invalid response.
Transfer-Encoding Plus Content-Length Is a Security-Sensitive Framing Combination
HTTP/1.1 has explicit precedence and recipient rules for message framing because different parsers disagreeing about where a message ends can create serious intermediary vulnerabilities.
The formatter flags both fields appearing together and preserves duplicate values. If the capture comes from a proxy-chain security incident, use raw protocol-aware tooling instead of relying on a forgiving text formatter to settle ambiguous bytes.
1xx, 204 and 304 Have Special Message-Content Semantics
Informational responses, 204 No Content and 304 Not Modified do not carry ordinary response content in the way a 200 response does. A pasted “body” after one of these status lines can be another response, a logging annotation or a tool reconstruction.
HEAD is another special case: whether content is expected depends on the request method, and a response capture alone may not include that context. This tool therefore does not guess HEAD semantics.
Redirect Status and Location Need to Be Read Together
A 301, 302, 303, 307 or 308 tells you a redirect-class response occurred, while Location identifies the target. The status also affects method rewriting/preservation rules, so “there is a Location header” is not the whole redirect story.
This formatter surfaces missing or repeated Location values, but it does not follow the redirect. Use a redirect-chain tool when you need the actual sequence and final destination.
HTTP/2 and HTTP/3 Can Be Displayed Like Text Without Being Text Protocols
DevTools and command-line clients often print a readable line such as HTTP/2 200. That is a human presentation. HTTP/2 and HTTP/3 use framed field representations rather than the HTTP/1.1 status-line/header-block wire syntax.
Yoryantra accepts those readable summaries for debugging while keeping the limitation visible so the formatted output is not mistaken for packet-level reconstruction.
Defines status-code semantics, fields, representations, redirects and message-content rules shared across HTTP versions.
Defines HTTP/1.1 textual response syntax, field parsing and message framing.