HTTP Request Formatter
Read an HTTP/1.x request as the protocol sees it: request line, headers, query, body, and message-framing warnings.
Paste a request from a log, proxy capture, test fixture, support ticket, API debugger or documentation example.
Sharing safety
- HTTP/1.0 and HTTP/1.1 request lines
- origin, absolute, authority and asterisk targets
- repeated/malformed fields and obsolete folding
- query parameters without turning + into a space
- JSON, URL-encoded and multipart body clues
- Host and message-framing inconsistencies
Request-line, headers, query fields, body interpretation and diagnostics will appear here.
Read the Request Line Before the Headers
An HTTP/1.x request starts with three pieces: the method, the request target, and the HTTP version. A normal request sent directly to an origin usually looks like GET /products?page=2 HTTP/1.1. A proxy can receive a complete absolute URI, CONNECT uses an authority such as example.com:443, and server-wide OPTIONS can use *.
Those forms are not cosmetic. They affect how a proxy reconstructs the target URI and how the Host field should line up with the request. If a request works directly but fails through a proxy, compare the request target and Host before changing application code.
Origin form: GET /items?q=desk HTTP/1.1 Absolute form: GET https://example.com/items?q=desk HTTP/1.1 Authority form: CONNECT example.com:443 HTTP/1.1 Asterisk form: OPTIONS * HTTP/1.1
Method Names Are Case-Sensitive
GET and get are different method tokens. Servers and frameworks often normalize familiar method names, which can hide this detail until a request reaches a stricter proxy, gateway, signature check, or test harness.
The same principle matters for CONNECT and OPTIONS because their request-target rules are tied to those exact standardized methods.
Content-Length Is a Byte Count
ASCII text often makes character count and byte count look the same. Add an emoji or an accented character and the numbers can diverge. HTTP message framing counts octets, not JavaScript characters.
The comparison here uses the UTF-8 byte length of the pasted body. Treat a mismatch as a clue, not proof that the original request was malformed. Logs and copied captures can normalize line endings, decompress content, or omit transfer framing before you ever paste them.
Transfer-Encoding and Content-Length Should Not Compete
HTTP/1.1 has strict message-length rules because two recipients must agree on exactly where a request ends. A request carrying both Transfer-Encoding and Content-Length deserves immediate attention. RFC 9112 treats that combination as a framing risk and discusses it directly in the context of request smuggling.
Repeated Content-Length fields also need care. Identical values can arise in old or intermediary-generated traffic, while conflicting values are a clear ambiguity. Do not fix a production capture by simply deleting whichever field looks inconvenient; trace how each hop parsed the original bytes.
A Plus Sign Is Not Always a Space
In a generic URI query component, + can be literal data. In application/x-www-form-urlencoded, a plus sign is the conventional encoding for a space. Applying form decoding to every query string can silently change values such as product codes, signatures, or search terms that contain a real plus.
Percent escapes are another common source of confusion. A percent sign that starts an encoded byte needs two hexadecimal digits. A malformed escape is left visible and reported instead of being silently repaired.
Content-Type Is a Claim About the Body
Content-Type: application/json says the enclosed representation is JSON. If the body does not parse as JSON, the useful fact is the disagreement itself. Reformatting malformed text until it looks valid can hide the bug you were trying to find.
Multipart bodies need a boundary parameter, and that boundary must appear in the body framing. URL-encoded forms use a different encoding model. Unknown media types are best kept as pasted text unless you know the format well enough to parse it deliberately.
Copied Requests Often Contain Live Credentials
Authorization, Cookie, API-key, token, and credential-like headers are often exactly what makes a failing request reproducible. They are also the fields most likely to become a security incident when a capture is pasted into a public ticket or screenshot.
Masking changes the formatted report and copied output; it does not erase the original textarea. Prefer placeholders whenever possible. If a real credential was shared outside its intended environment, rotate it instead of relying on redaction after the fact.
A Text Capture Is Not a Packet Capture
Debuggers, reverse proxies, logs, and browser tools often show a reconstructed request. They may normalize CRLF line endings, decode transfer coding, decompress content, hide TLS, or omit bytes that were present on the wire. That is why byte counts and framing notes should be checked against the original capture when the problem is low-level HTTP behavior.
HTTP/2 and HTTP/3 Look Different on the Wire
HTTP semantics carry across versions, but HTTP/2 and HTTP/3 do not send a textual METHOD /path HTTP/1.1 request line. They use framed fields and pseudo-fields such as :method,:scheme, :authority, and :path.
A debugging program may render those fields as HTTP/1-like text for readability. Treat that as a human-readable reconstruction, not the original HTTP/2 or HTTP/3 wire format.
HTTP Rules Worth Checking
Methods, fields, representations, target URIs, and semantics shared across HTTP versions.
Request-line syntax, request-target forms, Host, field parsing, Content-Length, Transfer-Encoding, and HTTP/1.1 message framing.