What is Checksum

A checksum is a small, fixed-size value computed by running every byte of a message through a deterministic function, so that changing any byte almost always changes the value — which lets whoever receives the data recompute the function and compare, catching corruption before it is trusted.

The problem it solves

When data moves between components — across a network link, off a disk, through RAM — bits flip. A cosmic ray flips a memory cell, a cable induces a burst error, a firmware bug drops a byte. The receiver has no way to know the bytes it holds are the bytes that were sent. A checksum attaches a compact fingerprint alongside the data so the receiver can answer one question cheaply: are these the bytes I was supposed to get? If not, it can raise an error or refetch from another replica instead of silently serving garbage. At scale this is not hypothetical: one petabyte is 8×10¹⁵ bits, so even a very low bit-error rate of 10⁻¹⁵/bit works out to roughly 8 flipped bits on every full scan of the data.

The important correction up front: a checksum is any function that folds data into a fixed-size fingerprint for integrity checking. It does not have to be a cryptographic hash. The workhorses of real systems are cheap, non-cryptographic algorithms — CRC32 (Ethernet frames, ZIP, PNG), Adler-32 (zlib), Fletcher, the 16-bit one's-complement Internet checksum (TCP/IP). Cryptographic hashes like SHA-256 are checksums too, but they are a heavyweight subset you reach for only when you must defend against a deliberate attacker, not merely random noise.

A worked example: Adler-32 on the bytes "Hi"

Adler-32 (used inside zlib) is simple enough to run by hand and shows the mechanism clearly. It keeps two running sums, A and B, both reduced modulo 65521. A starts at 1 and adds each byte; B accumulates A after every step. The final checksum is (B << 16) | A. The two-sum trick means the result depends not just on which bytes appear but on their order — a plain sum would give the same answer for "Hi" and "iH".

Input bytes: 'H' = 72, 'i' = 105.

Both sums are well under 65521, so the modulo is a no-op here. Final: A = 178 = 0xB2, B = 251 = 0xFB, giving checksum = (251 << 16) | 178 = 0x00FB00B2.

Now corrupt one bit. Suppose the 'H' (72, binary 01001000) has its low bit flipped in transit, becoming 'I' (73, 01001001):

New checksum: (253 << 16) | 179 = 0x00FD00B3. The receiver recomputes Adler-32 over the bytes it holds, gets 0x00FD00B3, compares it to the transmitted 0x00FB00B2, sees they differ, and rejects the data. A single flipped bit was caught by four additions.

Pitfalls

• A checksum detects accident, not attack. CRC32 and Adler-32 are unkeyed and public. An attacker who edits the data simply recomputes the checksum, and the tampering is invisible. If your threat model includes a malicious actor modifying data in flight or at rest, a plain checksum gives a false sense of safety — you need a cryptographic hash pinned by a trusted channel, or better, an HMAC (keyed) or digital signature.
• Storing the checksum next to the data. If the checksum lives in the same disk block, same packet, or same write path as the data, a fault that corrupts one can corrupt both — you end up verifying garbage against a matching garbage checksum. Robust systems store or transmit the checksum through an independent path, or use end-to-end checks (client computes, server verifies) so a bug in any single layer is caught.
• Collisions are guaranteed. A fixed-size output means many inputs map to the same value. A 32-bit checksum leaves roughly a 1-in-4-billion chance a corrupted payload still matches — fine for a network frame, dangerous for content addressing across billions of objects. Undersized checksums silently pass some corruptions.
• Checking at rest but not end-to-end. Verifying on read from disk does nothing for a bit that flips in RAM or a CPU register after verification and before use. Systems that care (ZFS, some databases) carry the checksum all the way to the point of consumption.
• Endianness and framing mismatches. Two correct implementations that disagree on byte order, initial value, or bit reflection (a classic CRC32 footgun) will flag valid data as corrupt. Pin the exact variant, not just "CRC32."

When to use which — and the trade-offs

"Add a checksum" is not one decision; it is choosing where you sit on a cost-versus-guarantee curve. The signals that point to each option:

• Parity bit / simple sum — 1 bit to a few bits. Catches an odd number of flips only; misses a double-bit error entirely. Use only where hardware is trivial and errors are rare and independent (some memory buses, serial links). Cheapest, weakest.
• CRC32 / Adler-32 / Fletcher — a few nanoseconds, often hardware-accelerated (SSE4.2 crc32 instruction). CRC is mathematically strong against burst errors, which is exactly what noisy channels produce, which is why it guards Ethernet frames, ZIP, and PNG. Gain: near-free, excellent random-error coverage. Cost: zero protection against a deliberate adversary. Choose this when you are defending against hardware and transmission faults in a non-adversarial setting.
• Cryptographic hash (SHA-256, BLAKE3) — orders of magnitude slower than CRC, produces 256 bits. Gain: collision resistance, so a distinct payload cannot be forged to match, and the fingerprint is stable enough to use as an identity (Git commits, container image digests, deduplication). Cost: CPU and 8x the storage of a 32-bit checksum; still not proof of authorship — anyone can compute SHA-256 of anything. Prefer this over CRC when data may be tampered with, or when you need a content address.
• HMAC / digital signature — a cryptographic hash plus a secret key (HMAC) or a private key (signature). Gain: integrity and authenticity — only a holder of the key could have produced it. Cost: key management, distribution, rotation. Prefer this over a bare SHA-256 when the checksum itself travels over the same untrusted channel as the data, so an attacker can't just recompute it.

Rule of thumb: CRC32 when the enemy is noise; SHA-256 when the enemy is a person; HMAC/signature when the enemy controls the wire. Reaching for SHA-256 to guard an internal disk block wastes CPU; reaching for CRC32 to verify a downloaded release binary is a security hole.

Takeaways

• A checksum folds all the bytes into a small fixed-size fingerprint; the receiver recomputes and compares to catch corruption cheaply.
• Most real checksums are non-cryptographic (CRC32, Adler-32, Internet checksum) — fast and great against random/burst errors, but forgeable and useless against an attacker.
• Reach for a cryptographic hash (SHA-256) for tamper detection or content addressing, and an HMAC/signature when the fingerprint shares an untrusted channel with the data.
• Guard against the practical traps: store the checksum on an independent path, size it for your object count, and verify end-to-end rather than only at rest.

Re-authored and deepened for this guide. Sources: RFC 1071 (Computing the Internet Checksum); RFC 1950 (ZLIB / Adler-32 specification); Philip Koopman, Better Embedded System Software and his CRC/checksum research (Carnegie Mellon); Martin Kleppmann, Designing Data-Intensive Applications (on end-to-end integrity and replica repair); the ZFS end-to-end checksum design notes. The original page's claim that a checksum is computed with a cryptographic hash function was corrected — cryptographic hashes are one heavyweight subset of checksums, not the definition.