The TCP checksum field is a 16-bit value in every TCP segment header that exists for one reason: error detection. It lets the receiving computer verify that a packet’s data wasn’t corrupted during transmission across the network. Before sending a segment, the TCP layer computes a checksum from the packet’s contents. The receiver runs the same calculation on arrival and compares the two values. A match means the data is almost certainly intact. A mismatch means something changed in transit.
How the Checksum Is Calculated
The algorithm treats the binary data in the segment as a series of 16-bit integers, adds them together using a method called one’s complement addition, and produces a single 16-bit result. This is sometimes called the “IP-style” checksum because the same general approach is used across several Internet protocols.
What makes the TCP checksum slightly unusual is that it doesn’t just cover the TCP header and payload. Before computing the value, the sender constructs a 12-byte “pseudo-header” that pulls in fields from the IP layer: the source IP address (4 bytes), the destination IP address (4 bytes), a reserved byte of zeroes, the protocol number identifying TCP, and the total length of the TCP segment. This pseudo-header is included in the checksum calculation but never actually transmitted.
The purpose of including IP addresses is to catch misdelivery. If a packet somehow arrives at the wrong destination, the receiver’s checksum calculation will use a different IP address than the sender used, causing a mismatch. This provides a layer of protection against routing errors that a checksum over the TCP data alone would miss.
What Happens When a Checksum Fails
When the receiver detects a checksum mismatch, it silently drops the segment. It doesn’t send an error message back to the sender. From the sender’s perspective, the packet simply vanished. TCP’s reliability mechanism then kicks in: the sender notices it never received an acknowledgment for that segment, waits for a timeout period, and retransmits it. If the underlying problem persists (a faulty network interface, for instance), the sender will keep retrying with invalid checksums and eventually close the connection, typically after about 60 seconds of failed attempts.
This behavior means checksum failures are invisible to applications. You won’t see an error message. You’ll see a connection that hangs, slows down, or drops entirely. That makes checksum-related problems notoriously difficult to debug in practice.
Known Limitations of the TCP Checksum
The 16-bit one’s complement checksum is lightweight by design, but it’s not particularly strong by modern standards. Research from Texas A&M University quantified its weakness: the TCP checksum fails to detect errors in roughly 1 out of every 16 million to 10 billion packets. For most everyday use, those odds are fine. For high-throughput systems moving billions of packets, undetected corruption becomes a real possibility.
The algorithm also has a specific blind spot: it cannot detect reordered data. If two 16-bit chunks within a segment swap positions during transmission, the checksum value stays the same. Stronger alternatives like CRC-32 catch this kind of error reliably, with an undetected error probability proportional to 1 in roughly 4 billion (compared to 1 in 65,536 for a 16-bit checksum).
This is why protocols that sit on top of TCP, like those used in databases and storage systems, often add their own CRC checks. The TCP checksum was designed in an era when CPU cycles were precious and network speeds were slow. It provides a baseline level of protection, not a guarantee.
Hardware Offloading
Computing a checksum for every outgoing and incoming packet can add up, especially at high data rates. Modern network interface cards (NICs) handle this automatically through a feature called checksum offloading. Instead of the CPU calculating the checksum in software, the NIC computes it in hardware as the packet leaves or arrives.
The Linux kernel, for example, has a detailed offloading interface where the operating system tells the NIC where in the packet to start the calculation and where to store the result. The NIC then fills in the correct value. If a NIC doesn’t support offloading (or the feature is disabled), the kernel falls back to computing it in software. This is largely invisible to you as a user, but it’s one reason packet captures taken on the sending machine sometimes show incorrect checksums. The capture tool grabs the packet before the NIC has filled in the real value.
Differences With IPv6
When TCP runs over IPv6 instead of IPv4, the pseudo-header used in the checksum calculation changes to accommodate IPv6’s longer 128-bit addresses. The core concept is identical: IP addresses and protocol information are folded into the checksum to guard against misdelivery. IPv6 actually makes the transport-layer checksum more important, because IPv6 itself dropped the header checksum that IPv4 included. TCP’s checksum becomes the primary integrity check for ensuring a segment reached the right destination with its data intact.
The current TCP specification, RFC 9293 (which replaced the original RFC 793), confirms the checksum’s role as one of three pillars of TCP reliability. Sequence numbers detect lost packets, per-segment checksums detect corrupted data, and retransmission corrects both. The checksum field remains mandatory in every TCP segment, with no option to skip it.