Guide
Computing the IPv4 header checksum step by step
The IPv4 header ends with a 16-bit checksum that protects the header, though not the data. It is simple enough to compute on paper, which makes it a favourite exercise in networking courses and a useful debugging step when a hand-built packet is dropped. The page performs the calculation, verifies a stored checksum and shows each stage.
The algorithm
Take the header as a sequence of 16-bit words, in big-endian order. Set the checksum field to zero. Add all words using ordinary integer addition. If the sum is larger than 16 bits, take the carry bits and add them back to the low 16 bits, repeating until none remain; this is one’s-complement addition. Finally invert every bit. The result is the checksum. The scheme is defined in RFC 791 and the method described in RFC 1071. To verify a received header, add all words including the checksum: the folded sum should be 0xFFFF, so the inverted value is zero.
Using the page
Paste the header bytes in hexadecimal; spaces are optional and a header of 20 to 60 bytes is accepted, since options lengthen the header. The page reports whether the checksum stored in the header is correct, shows both the stored and the computed values, and prints the header with the correct checksum written in, ready to copy. The calculation panel lists the 16-bit words, the sum with the checksum field zeroed, the folded sum and the inverted result. The sample is the standard textbook header.
Why it matters
A header with a wrong checksum is discarded by the first router or host that checks it, without an error message. Anyone writing a packet generator, a raw-socket program or an embedded stack hits this; a correct-looking packet that never arrives is often a checksum problem. Because the TTL changes at every hop, routers must update the checksum each time, and hardware does so incrementally. The check protects against corruption in memory and on the path, but it is weak: it cannot detect swapped words, and it is the reason the upper layers carry their own checksums.
A worked example
The sample header is 45 00 00 73 00 00 40 00 40 11 b8 61 c0 a8 00 01 c0 a8 00 c7. With the checksum field set to 0000 the ten words are 4500 0073 0000 4000 4011 0000 c0a8 0001 c0a8 00c7. Their sum is 2479c. Folding the carry (the leading 2) back in gives 479c + 2 = 479e. Inverting gives 0xB861, which matches the stored value, so the page reports that the checksum in the header is correct. The source is 192.168.0.1, the destination 192.168.0.199 and the protocol 17 (UDP).
Limits
Only the IPv4 header checksum is covered. TCP and UDP checksums use a pseudo-header and are verified by the Packet Header Decoder when the entire packet is present. The page assumes the bytes you paste are the actual header; if you paste a longer packet, give only the header portion, whose length is in the first byte (the low nibble times four).
Related tools
- Packet Header Decoder decodes the full packet and checks the transport checksums.
- Hex to Binary Converter shows the bits of a word.
- Hex to Decimal Converter converts a field’s value for the hand calculation.
- IP to Hex Converter writes an address as the four bytes you need in a header.
Checked against the current version of the IPv4 Checksum Calculator on .

