Packet Header Decoder

A packet capture shows rows in a list, but sometimes all you have is a block of hexadecimal copied from a log, a book or a colleague. Decoding the bytes by hand means counting offsets and remembering which field is where. This page names every field of the headers it understands and checks the checksums, entirely in your browser.

What it understands

Choose “An IPv4 or IPv6 header” to start at the IP layer, or “An Ethernet frame” to start with the link-layer header. The decoder reads the IP header, then the transport header it announces: TCP, UDP or ICMP. For IPv4 it shows version and header length, DSCP and ECN, total length, identification, flags, fragment offset, TTL, protocol, header checksum and the two addresses. For TCP it adds ports, sequence and acknowledgement numbers, window, flags and options; for UDP the ports, length and checksum. The remaining bytes are shown as the payload.

Input formats

Paste the bytes as hex with or without spaces. A dump with offsets, as printed by tcpdump -x, and the hex copied from Wireshark’s “Copy as Hex Stream” both work. Offset columns in a dump are tolerated, as the input box says. Everything is decoded locally, so a packet containing real addresses or payload never leaves your device.

Checksums and their traps

The IPv4 header checksum is always recomputed, and the page prints “correct” or “wrong” next to the stored value. TCP and UDP checksums cover the data and a pseudo-header, so they can be checked only if the whole packet is present. A frequent source of false alarms is checksum offload: the operating system hands the network card an incomplete checksum and the card fills it in later, so a capture taken on the sending host shows wrong values for packets that left the machine fine.

A worked example

The sample is a DNS query sent from 192.168.1.10 to 8.8.8.8. The IPv4 header is 20 bytes with version 4, a total length of 57 bytes, identification 0x1a2b, the Don’t Fragment flag, a TTL of 64 and protocol 17 (UDP). Its checksum 0x4ec7 is reported correct. The UDP header goes from source port 50010 to destination port 53, with length 37 bytes and checksum 0x88b0, also correct. The 29-byte payload begins 12 34 01 00 00 01 (a DNS transaction ID, flags and one question) and spells out the name example.com in DNS label form.

Limits

The decoder handles IPv4, IPv6, TCP, UDP and ICMP only. IPv6 extension headers and other protocols are displayed as payload bytes. Fragmented packets are not reassembled, and options are listed but not all interpreted in depth. The tool is not a capture application: it cannot open pcap files or follow streams. Use IPv4 Checksum Calculator to see the checksum arithmetic in detail.

Offsets worth remembering

Bytes are counted from zero at the start of the IP header. In IPv4, byte 0 holds the version and header length, bytes 2 and 3 the total length, byte 8 the TTL, byte 9 the protocol number, bytes 10 and 11 the header checksum, bytes 12 to 15 the source address and bytes 16 to 19 the destination. In the transport header that follows, the first four bytes of both TCP and UDP are the source and destination ports. Knowing these positions lets you read a hex dump by eye when no analyser is available.

Related tools

• IPv4 Checksum Calculator shows the sum, fold and invert steps.
• TCP Flags Decoder explains the flag byte of a TCP header.
• Wireshark Filter Builder writes the filters to capture the packets you want to decode.
• Hex to Binary Converter turns single fields into bits.