Checksums versus cryptographic hashes
A CRC32 and a SHA-256 both turn data into a short fixed-length value, and both will catch a file that got corrupted in transit. That surface similarity leads people to treat them as interchangeable. They are not. One class defends against accidents, the other against adversaries, and using the wrong one leaves a real hole.
Two different jobs
A checksum like CRC32 or Adler-32 answers one question: did the data change by accident. These algorithms are designed to be fast and to reliably detect the kinds of errors that happen in the physical world, flipped bits from a bad cable, a dropped packet, a scratched disk. They are excellent at that job and cheap enough to run on every network frame.
A cryptographic hash like SHA-256 answers a harder question: can anyone produce different data with the same digest. Its security property is collision resistance, the practical impossibility of finding two inputs that hash to the same value, even for someone actively trying. This is what lets a hash stand in for the data itself in signatures, certificates, and content addressing.
| Property | CRC32 / Adler-32 | SHA-256 |
|---|---|---|
| Primary goal | detect accidental errors | resist deliberate tampering |
| Output size | 32 bits | 256 bits |
| Speed | very fast | fast but heavier |
| Find a collision on purpose | trivial | computationally infeasible |
| Reverse-engineer input near it | easy | infeasible |
Why a checksum cannot resist tampering
The problem with a 32-bit checksum against an attacker is not only its short length, though 32 bits is far too few. It is that CRC is a linear function. Because of that linearity, an attacker who changes the data can compute exactly what further bytes to add or flip so the CRC comes out to any value they want. CRC was never meant to stop this; it was meant to catch noise, and it does.
So if a download page publishes a CRC32 next to a file, that CRC tells you the file arrived intact from wherever you fetched it. It tells you nothing about whether the file on the server is the one the author intended. An attacker who replaced the file could trivially publish a matching CRC. Only a cryptographic hash, delivered through a channel the attacker does not control, gives you tamper evidence.
Why you cannot swap them
The two are not substitutes in either direction.
- You cannot use CRC32 where you need security. It has no collision resistance, so it cannot back a digital signature, a certificate fingerprint, or a content-addressed store. Treating a CRC as a security check is a false sense of safety.
- You usually should not use SHA-256 where a checksum suffices and speed matters at scale, such as per-packet error detection in a protocol, though modern hardware narrows this gap. More importantly, SHA-256 does not give you the specific error-detection guarantees that CRC polynomials are engineered for, such as catching all burst errors up to a certain length. CRC is mathematically tuned for exactly the error patterns that hardware produces.
A note on the middle ground: MD5 and SHA-1 are cryptographic hashes that are now broken for collision resistance. Practical collisions exist for both. They are fine as fast integrity checks against accidental corruption, in the same role as a long checksum, but they must not be used for security. If security is the goal, use SHA-256 or SHA-3.
The short version: match the tool to the threat. Accidental corruption calls for a checksum, a deliberate adversary calls for a strong cryptographic hash, and the publication channel for the digest matters as much as the algorithm. To compare how a one-byte change ripples through different algorithms, run the same input through several at once in the Hash Generator.