IPv4 Header Decoder
Decode a raw IPv4 header from hex — version, IHL, DSCP/ECN, flags, fragment offset, TTL, protocol, addresses — and verify the header checksum. Decode only; nothing is sent anywhere.
This tool handles input and primary processing in your browser and is designed not to send the input to QuickKit’s server.
Decoded header
| Version | — |
|---|---|
| IHL (32-bit words) | — |
| Header length | — |
| DSCP | — |
| ECN | — |
| Total length | — |
| Identification | — |
| Flags | — |
| Fragment offset | — |
| TTL | — |
| Protocol | — |
| Header checksum | — |
| Checksum status | — |
| Source address | — |
| Destination address | — |
| Options | — |
Header bytes
How it works
Paste an IPv4 header as hexadecimal (at least 20 bytes) and choose the input format. Raw hex keeps every hex digit: a continuous string works, as does hex with 0x prefixes, spaces, colons, hyphens, dots or newlines, and no column is ever treated as an offset. Hexdump reads xxd (00000000:), tcpdump -x (0x0000:) and hexdump -C lines: every line needs an offset that continues the previous line, and the offsets and pipe-delimited ASCII gutters are removed. An ASCII column without pipes (xxd, tcpdump -X, Wireshark “Copy Bytes as Hex + ASCII Dump”) is removed only when it shows exactly the bytes on its line (bytes 0x20–0x7e as themselves, others as a dot); otherwise the line is rejected. The format is never guessed. This tool decodes locally and never transmits anything.
Header length is IHL x 4 bytes and IHL below 5 is invalid. DSCP and ECN are read from the former ToS byte; ECN is reported as a 2-bit key (00 Not-ECT, 01 ECT(1), 10 ECT(0), 11 CE) and well-known DSCP values are named (CS0-CS7, AF11-AF43, EF); unknown DSCP values are left unnamed. The fragment offset is shown both in 8-byte units (as stored) and in bytes. The header checksum is recomputed with the checksum field treated as zero and compared with the value in the header.
Fields that contradict RFC 791 are still decoded but flagged as a malformed header: the reserved flag bit set (it must be zero), a total length below the header length (total length is header plus data; captures from TSO/offload hardware can show 0), a non-final fragment that is empty or whose data is not a multiple of 8 bytes, and a fragment whose data would end beyond what a 65535-byte datagram can carry. DF on a fragment is not flagged: RFC 6864 allows DF to forbid further fragmentation of an already fragmented datagram.
When IHL is greater than 5 the tool reports that options are present, their total byte length and their raw hex, but it does not parse individual option types. The payload after the header is ignored.