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.

Debugging

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 — GET
  • 50 4F 53 54 — POST
  • 50 55 54 — PUT
  • 44 45 4C 45 54 45 — DELETE
  • 48 45 41 44 — HEAD
  • 4F 50 54 49 4F 4E 53 — OPTIONS
  • 50 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-Length header (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.

Try It — Hex Editor

Open full tool