HTTP Request Parser

Break a raw HTTP/1.x request into request-line, headers, query parameters, cookies, and body details.

Raw HTTP Request

Paste a raw HTTP request copied from logs, proxy tools, API debugging output, browser tooling, or server traces.

Parsing Options

Body Parsing

Output Format

Scheme for relative targets

Decode query parametersPercent-decode query names and values. A literal + stays + because URI query syntax does not universally define it as a space.Include sensitive headers in outputInclude recognized credential, cookie, token, and key-like header values in copied output. Request bodies are never scrubbed automatically.

Parsed Output

Parsed HTTP request output will appear here.

Parsing stays in the browser and never sends the pasted request. Sensitive-value masking applies to recognized headers and query keys; arbitrary body text is left untouched.

Reading an HTTP/1.x Request Without Inventing Missing Context

A textual HTTP/1.x request has a request line, field lines, an empty line, and optionally a message body. The scheme is not present in an origin-form request such as GET /api HTTP/1.1, so HTTPS or HTTP must be chosen explicitly when a full URL is reconstructed.

HTTP/2 and HTTP/3 do not use the HTTP/1.x request-line format on the wire. Paste a textual HTTP/1.0 or HTTP/1.1 message here rather than pseudo-header or binary framing dumps.

Request Targets Have Four Forms

origin-form: a path and optional query, normally used when talking directly to an origin server.
absolute-form: a complete URI, normally sent to an HTTP proxy.
authority-form: host and port for CONNECT.
asterisk-form: * for server-wide OPTIONS.

The parser checks the target against the method instead of forcing every request through a URL constructor. That prevents CONNECT and OPTIONS * requests from being misrepresented as ordinary paths.

Header Syntax Is Security-Relevant

HTTP field names are tokens and whitespace before the colon is invalid. Obsolete folded field lines are rejected rather than silently unfolded. For HTTP/1.1, exactly one Host field is required. Requests containing both Transfer-Encoding and Content-Length are rejected because ambiguous message framing is a well-known request-smuggling boundary.

Body Parsing Follows Content-Type

Auto mode parses JSON only for application/json or a +json media type, and parses form data only for application/x-www-form-urlencoded. A body that merely starts with a brace is not enough to call it JSON.

Transfer-coded bodies are left as pasted wire text; chunk framing is not decoded here. The UTF-8 byte count is calculated from the pasted body and compared with a simple Content-Length value when one is present. That is a debugging aid, not proof of the bytes that originally crossed the network.

Turning a Parsed Request into cURL

Generated commands use POSIX-shell quoting and --data-raw so a leading @ in body text is not treated as a filename. Recognized secrets are replaced with placeholders unless you explicitly include them. Transfer-Encoding framing is not converted because curl would need the decoded payload rather than the pasted chunk syntax.

Primary References

RFC 9110 defines HTTP semantics, methods, and field names. RFC 9112 defines HTTP/1.1 message syntax, request-target forms, Host requirements, field-line parsing, and message framing.