A checksum is a fixed-size fingerprint computed from data, small enough to compare at a glance and sensitive enough that changing even one bit of the input changes the output. That definition covers three genuinely different mechanisms, though — a byte-sum, a CRC, and a cryptographic hash like SHA-256 all produce "a fingerprint that changes when the data does," but they catch different kinds of damage, and only one of them survives contact with someone deliberately trying to fool it.
The weak end: adding up the bytes
The simplest possible checksum sums every byte (usually wrapping at some fixed width) and calls the total the fingerprint. It catches plenty of accidental corruption — flip a bit anywhere and the sum changes — but it has an obvious blind spot: addition doesn't care about order. Bytes [10, 20, 30] and the reordered [20, 10, 30] both sum to the same value, so a checksum built this way is blind to any corruption that merely rearranges data rather than changing what bytes are present — exactly the kind of error a corrupted network packet or a misaligned disk read can produce.
The middle: CRC (Cyclic Redundancy Check)
CRC fixes the reordering blind spot by treating the whole input as one large binary number and computing the remainder of dividing it by a fixed constant (the "polynomial") — arithmetic where position matters, unlike a plain sum. In practice it's computed a byte at a time using a precomputed 256-entry lookup table, which is what makes it fast enough to run on every packet on a network link or every block written to a disk. CRC-32 is standardized enough that implementations agree exactly — running the bytes of the string 123456789 through the same CRC-32 variant ZIP and PNG use (polynomial 0xEDB88320) produces cbf43926 in every correct implementation, including this site's own Checksum Generator.
What CRC doesn't give you is any resistance to a deliberate attacker. The math is linear and uses no secret key, which means anyone who can modify the data is also able to compute exactly what adjustment produces whatever target CRC they want — the checksum constrains accidental damage, not intentional tampering. That's a completely reasonable trade for what CRC is actually used for (catching transmission and storage errors), and exactly why it's the wrong tool the moment "did this get corrupted" becomes "did someone tamper with this."
The strong end: cryptographic hashes
SHA-256, SHA-512, and their relatives are checksums too, in the sense that they're still a fixed-size fingerprint of arbitrary-length data — but they add a property CRC doesn't have: collision resistance, meaning it's computationally infeasible to find two different inputs that hash to the same output, or to start from an existing file and work backward to a modification that preserves its hash. That property is what makes a SHA-256 checksum trustworthy even when the person publishing the file and the person checking it don't trust each other — a download page posting a SHA-256 value next to a file is asserting something a CRC-32 next to the same file couldn't honestly assert. See MD5 vs SHA-256 vs SHA-512 for why MD5 and SHA-1 no longer qualify despite being cryptographic hashes by design — their collision resistance is broken in practice, which is exactly the property that mattered.
A different flavor: check digits
Credit card numbers, ISBNs, and IBANs embed a checksum directly inside the identifier as one or more extra digits, computed with the Luhn algorithm for card numbers: double every second digit from the right, subtract 9 from anything over 9, sum everything, and a valid number sums to a multiple of 10. Change the final digit of a real test number like 4111111111111111 and the Luhn check correctly fails. This isn't remotely a security measure — it exists to catch a mistyped or transposed digit at entry time, not fraud, and doesn't require touching a network to check.
Common misunderstandings specific to this case
- A matching checksum proves the file matches what was published — not that what was published is safe. If a compromised download page serves malware alongside a correctly computed checksum for that same malware, the checksum matches perfectly. It verifies transport integrity, not the publisher's trustworthiness.
- Treating CRC-32 or MD5 as tamper-evident. Both are still genuinely useful for catching accidental corruption — that's not nothing — but neither should be the checksum you trust when the question is "could someone have changed this on purpose."
- Comparing hex checksums case-sensitively.
CBF43926andcbf43926are the same value; a naive string comparison treats them as different. Hash Verifier normalizes case before comparing for exactly this reason. - Expecting a checksum to fix, not just catch, corruption. A checksum tells you data is damaged; it can't tell you what the undamaged data was. Actually recovering from corruption needs redundancy built in ahead of time — erasure coding, RAID parity, Reed-Solomon codes — a different, more expensive technology than a checksum entirely.
Try it yourself
Checksum Generator computes CRC-32, MD5, SHA-1, SHA-256, and SHA-512 for a file side by side, so you can see exactly how differently each one behaves on the same input. Hash Verifier checks a value against an expected hash without you comparing long strings by eye, and File Hash Calculator covers just the cryptographic hashes if CRC-32 isn't relevant to what you're checking. All run entirely in your browser — nothing you check is ever uploaded.