Back

HTTP Message Parser

Parse and inspect HTTP/1.x and HTTP/2 messages including requests, responses, and curl verbose output. View headers, status codes, and bodies in a structured format. Supports automatic body type detection for JSON, HTML, and XML content.

Specifications

Common Use Cases

  • Debug HTTP requests from browser network tab
  • Analyze API responses
  • Parse curl -v output for troubleshooting
  • Inspect webhook payloads
  • Review HTTP headers for security analysis

Features

  • Parse HTTP/1.x and HTTP/2 requests and responses
  • Parse curl -v verbose output format
  • Display status codes with color-coded categories (2xx, 3xx, 4xx, 5xx)
  • Separate request and response headers for curl output
  • Automatic body content type detection (JSON, HTML, XML)
  • Dynamic body tool rendering (lazy-loads JSONTool, HTMLTool, etc. for body content)
  • Expand/collapse body sections
  • Copy headers or body to clipboard

Examples

HTTP GET Request

Try it →

A simple GET request with headers

GET /api/users HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer token123

HTTP Response

Try it →

A 200 OK response with JSON body

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 27

{"name":"John","age":30}

curl -v Output

Try it →

Verbose curl output with request and response

* Trying 93.184.216.34:443...
* Connected to example.com
> GET /api HTTP/1.1
> Host: example.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
<
{"status":"ok"}

Tips

  • Paste curl -v output directly - request and response headers are parsed separately.
  • Click "Decode as JSON/HTML/XML" to chain the body to the appropriate decoder.
  • Status codes are color-coded: green (2xx), blue (3xx), yellow (4xx), red (5xx).

Understanding HTTP Message

HTTP messages are the fundamental units of communication in the Hypertext Transfer Protocol. Every interaction between a web client and server consists of a request message and a response message. Understanding their structure is essential for debugging APIs, analyzing network traffic, and building web services.

An HTTP request starts with a request line containing the method (GET, POST, PUT, DELETE), the target path, and the protocol version. This is followed by header fields (key-value pairs), a blank line, and an optional body. The method indicates the intended action: GET retrieves data, POST submits data, PUT replaces a resource, DELETE removes it, and PATCH partially updates it.

An HTTP response starts with a status line containing the protocol version, a three-digit status code, and a reason phrase. Status codes are grouped by class: 2xx for success (200 OK, 201 Created), 3xx for redirection (301 Moved, 304 Not Modified), 4xx for client errors (400 Bad Request, 401 Unauthorized, 404 Not Found), and 5xx for server errors (500 Internal Server Error, 502 Bad Gateway).

The curl command-line tool with the -v (verbose) flag outputs both the request and response in a distinctive format using > for sent data and < for received data. This output format is one of the most common ways developers encounter raw HTTP messages, making curl -v parsing an essential debugging capability.

HTTP/1.1 is text-based and sends one request per TCP connection at a time (pipelining exists but is poorly supported). HTTP/2 is a binary protocol that multiplexes multiple requests over a single connection, supports server push, and compresses headers with HPACK. HTTP/2 significantly reduces latency for modern websites. The semantics — methods, status codes, and headers — remain the same across both versions; only the wire format differs.

In curl -v output, lines starting with > are data sent to the server (the request), lines starting with < are data received from the server (the response), and lines starting with * are curl informational messages about connection details and TLS negotiation. A blank line containing just > or < separates headers from the body. This tool parses all three sections automatically.

Status codes follow a well-defined numeric scheme: 1xx codes are informational (100 Continue), 2xx indicates success (200 OK, 201 Created, 204 No Content), 3xx signals redirection (301 Permanent, 302 Found, 304 Not Modified), 4xx represents client errors (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests), and 5xx covers server errors (500 Internal Error, 502 Bad Gateway, 503 Service Unavailable).

← Back to all tools