Checksums, Hashes and Parity Bits

Parity bits, checksums, and cryptographic hashes are three tools for catching data errors — but they do very different jobs. Knowing what each one detects (and what it can't) clears up a surprising amount of confusion about how digital integrity actually works.

They all boil down to the same instinct: attach a little extra information to your data so you can later ask "did this arrive intact?" But a parity bit, a checksum, and a SHA-256 hash sit at very different points on the spectrum of power and purpose. Let's meet each one, see what it catches, and lay them side by side. 🐾

What is a parity bit?

A parity bit is the simplest error check there is: a single extra bit added to a group of bits so that the total number of 1s is always even (even parity) or always odd (odd parity). The sender counts the 1s, sets the parity bit to make the count match the chosen rule, and sends it along.

The receiver counts again. If the count breaks the rule, at least one bit flipped in transit. A parity bit detects any odd number of bit errors — one, three, five — but it's blind to an even number, because two flips cancel out and leave the count looking correct. And crucially, it can't tell you which bit went wrong, so it can only detect, never correct. To go from detection to repair you need the cleverer arrangement of Hamming codes.

What is a checksum?

A checksum scales the idea up. Instead of one bit, you compute a small summary value from the whole message — often by adding up its bytes, or with a more elaborate calculation — and send that value alongside the data. The receiver recomputes the summary and compares. A mismatch means corruption.

A simple additive checksum catches more than a parity bit but still has blind spots — errors that happen to cancel out in the sum slip through. That's why serious systems use a stronger variant called a CRC (cyclic redundancy check), which uses polynomial math to reliably catch the kinds of burst errors that hit real communication lines. Networks and storage formats lean on CRCs heavily to spot damaged data and trigger a resend, an approach explored in error detection vs error correction.

What is a cryptographic hash?

A cryptographic hash is a different animal with a different goal. It runs the data through a one-way function to produce a fixed-length digest — a fingerprint of the content. The older MD5 produces a 128-bit digest; the modern SHA-256 produces a 256-bit one. Change even a single bit of the input and the digest changes completely and unpredictably.

Hashes aren't really about accidental errors — they're about integrity and identity. Because it's practically impossible to craft a different input with the same SHA-256 digest, a matching hash gives strong assurance that a file is exactly the one you expect and hasn't been tampered with. That's why downloads publish hashes and why version-control systems identify content by hash. Note that MD5 is now considered broken for security use and survives mainly as a quick, non-security checksum.

A checksum asks "did this get corrupted by accident?" A cryptographic hash asks "is this exactly the data I think it is, with nothing tampered?" Same shape, very different guarantees.

What does each one actually detect?

The crucial thing is to match the tool to the job. None of these three corrects errors — that takes redundancy schemes like Hamming or Reed–Solomon. What they offer is detection and, in the hash's case, verification of identity.

Tool	Size added	Detects	Main purpose	Corrects errors?
Parity bit	1 bit	Any odd number of bit flips	Cheap single-bit error detection	No
Checksum / CRC	A few bytes	Most accidental and burst errors	Detecting corrupted data blocks	No
Cryptographic hash	Fixed digest (e.g. 256 bits)	Any change, including tampering	Integrity and identity verification	No

Why can't these tools correct errors?

All three are one-way summaries: they compress the message down to a small value, so they throw away the information needed to reconstruct the original. A parity bit tells you a count is off but not which bit; a checksum tells you the summary doesn't match but not how to fix it; a hash tells you the data changed but says nothing about the correct version.

Correction requires more redundancy, structured so it points to the error's location and its right value — precisely what detection tools deliberately don't carry, to stay small. When you need repair rather than just a warning, you reach for error-correcting codes, as covered in Reed–Solomon error correction.

Which should you use when?

Pick by the question you're actually asking:

• "Did a single bit flip in a tiny group?" A parity bit is cheap and adequate — this is how it's used inside some memory and serial links.
• "Did this block of data get corrupted in transit or storage?" A checksum or CRC is the workhorse, standard in network packets and file formats.
• "Is this exactly the file I expect, untampered?" A cryptographic hash like SHA-256 is the right tool, used for downloads, signatures, and content addressing.
• "Can it fix damage on its own, with no resend?" None of these — you need an error-correcting code.

How does this relate to QR codes?

QR codes actually sit in the correction camp rather than the detection camp: they use Reed–Solomon coding to rebuild damaged data, not just flag it. But the family resemblance is clear — a QR code adds structured redundancy to guard its message, the same instinct behind every parity bit and checksum, just turned up to the point of full repair. Understanding these simpler cousins makes the QR approach easier to appreciate, as our QR code error correction guide shows.

There's also a close everyday relative worth knowing: the humble check digit on barcodes and card numbers, which is essentially a checksum you can compute by hand to catch typos and misreads.

Parity, checksums, and hashes in one sentence

A parity bit catches a single flipped bit, a checksum or CRC catches corrupted blocks, and a cryptographic hash verifies exact identity and integrity — three detectors of increasing power, none of which corrects errors, all sharing the idea of a small guard value attached to your data.

Curious how redundancy makes data resilient? You can create a free QR code with QR Puppy and see error protection built right into a scannable grid.

Frequently asked questions

Can a parity bit detect two flipped bits?

No. It detects any odd number of flips — one, three, five — but two flips cancel out and leave the parity looking correct. That blind spot is why parity is only used where single-bit errors are the main concern.

What's the difference between a checksum and a hash?

A checksum is a lightweight summary meant to catch accidental corruption, while a cryptographic hash is designed to verify exact identity and resist deliberate tampering. Hashes are far stronger and larger, but slower to compute, and both merely detect rather than correct.

Is MD5 still safe to use?

Not for security. MD5 is considered broken because attackers can craft different inputs with the same digest, so use SHA-256 for anything involving trust. MD5 lingers only as a quick, non-security integrity check.

Do checksums and hashes fix errors?

No, they only detect that something changed. Fixing damage without a resend requires an error-correcting code such as Hamming or Reed–Solomon, which carries extra redundancy specifically for reconstruction.

Which of these do QR codes use?

QR codes go beyond simple detection and use Reed–Solomon error correction to rebuild damaged data. The same underlying idea — attaching structured redundancy to protect a message — connects them to parity bits and checksums.