HTTP Request in Hex Dump Format
Learn how HTTP requests look in hexadecimal when captured from network traffic. Identify methods, headers, and body boundaries in raw hex packet data.
Hex
47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A
ASCII
GET / HTTP/1.1\r\n
Detailed Explanation
HTTP is a text-based protocol, which means every component of an HTTP request — the method, URL, headers, and text body — is composed of ASCII characters. When viewed in a hex editor or packet capture, HTTP traffic is both readable in the ASCII column and analyzable at the byte level.
A minimal HTTP GET request in hex:
47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A GET / HTTP/1.1..
48 6F 73 74 3A 20 65 78 61 6D 70 6C 65 2E 63 6F Host: example.co
6D 0D 0A 0D 0A m....
Byte-by-byte breakdown of the request line:
| Hex | ASCII | Component |
|---|---|---|
47 45 54 |
GET | HTTP method |
20 |
(space) | Separator |
2F |
/ | Request URI (root path) |
20 |
(space) | Separator |
48 54 54 50 2F 31 2E 31 |
HTTP/1.1 | Protocol version |
0D 0A |
\r\n | CRLF line terminator |
Identifying HTTP methods in hex:
Each HTTP method has a distinctive hex pattern:
47 45 54— GET50 4F 53 54— POST50 55 54— PUT44 45 4C 45 54 45— DELETE48 45 41 44— HEAD4F 50 54 49 4F 4E 53— OPTIONS50 41 54 43 48— PATCH
The header/body boundary:
The most important pattern to recognize in HTTP hex dumps is the double CRLF that separates headers from the body: 0D 0A 0D 0A (four bytes). Everything before this sequence is headers; everything after is the message body. In a long packet capture, searching for this four-byte pattern is the fastest way to locate where response content begins.
Content-Length and Transfer-Encoding:
After the double CRLF boundary, the body length is determined by either:
- The
Content-Lengthheader (specifies exact byte count) - Chunked transfer encoding (each chunk starts with its hex size in ASCII, followed by CRLF)
In chunked encoding, you will see patterns like 31 46 46 0D 0A which is ASCII "1FF\r\n" meaning the next 511 bytes are a chunk of body data.
HTTPS and encrypted traffic:
If the connection uses TLS/HTTPS, the hex dump will show the TLS handshake (starting with 16 03 01 for a TLS ClientHello) followed by encrypted application data that appears as random-looking bytes. To view the actual HTTP content, you need the TLS session keys for decryption, or you must capture the traffic at a point where it is already decrypted (such as a proxy or local loopback).
Common header patterns in hex:
43 6F 6E 74 65 6E 74 2D 54 79 70 65— "Content-Type"43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68— "Content-Length"41 75 74 68 6F 72 69 7A 61 74 69 6F 6E— "Authorization"
Recognizing these patterns in hex dumps allows quick identification of key headers without needing full ASCII rendering.
Use Case
Security analysts and network engineers examine HTTP requests in hex when debugging proxy issues, analyzing network captures in Wireshark, testing API endpoints with raw socket connections, or investigating suspicious traffic.