How a computer knows a file isn’t broken.

Every time a file is written, copied, transmitted or simply left sitting on a disk for a few years, there is a small chance that some bit of it changes on its own. Not often. But “not often” multiplied by trillions of bits and a decade of Tuesdays stops being a rounding error. Nearly every layer of a computer is therefore quietly checking itself, all the time, using a handful of ideas that get steadily cleverer — and it is worth knowing which layers only notice the damage and which ones actually fix it.

Bits really do flip

The causes are unglamorous and entirely physical:

• Flash memory leaks. An SSD or USB stick stores a bit as trapped electrical charge. Charge escapes — slowly, faster when hot, and faster still in cells that have been rewritten thousands of times.
• Magnetic media weakens. The tiny magnetised regions on a hard disk platter lose definition with age and heat.
• Radiation. Background radiation and cosmic-ray secondaries can deposit enough charge in a memory cell to flip it outright. This is a genuine, measured phenomenon, not folklore — it is precisely why servers use error-correcting memory.
• Everything in between. A marginal cable, an overheating controller, a flaky power supply. Data has to travel, and travel is where it gets hurt.

What makes this dangerous is not the rate. It is the silence. A corrupted spreadsheet generally opens without complaint and is simply, subtly wrong — and then it gets backed up, and the good copy ages out of retention, and nobody finds out for a year.

Level 1: the parity bit — one bit of doubt

The oldest trick in the book. Alongside each byte, store one extra bit that records whether the number of 1s in it was even or odd. If the byte later has an even count where it should be odd, something changed.

It is beautifully cheap and deeply limited. It catches any single flip — but it cannot tell you which bit went wrong, so it can’t repair anything. And if two bits flip, the count comes out right again and the error passes unnoticed. Parity is a smoke alarm with no address on it.

Level 2: checksums and CRC — catching the damage

The obvious improvement is to summarise the whole block rather than a single byte. The naive version simply adds all the values up and stores the total; if the total no longer matches, something moved. That is a checksum, and the naive version is poor — swap two bytes around and the sum is unchanged.

What everything actually uses is CRC (cyclic redundancy check), most often CRC-32. Rather than adding bytes, it treats the entire block as one enormous binary number and divides it by a carefully chosen constant, keeping the remainder as the check value. Because every bit of the input influences the division, changing anything at all — including reordering — changes the remainder.

CRC-32 catches every single-bit error, every burst of consecutive damage up to 32 bits, and the overwhelming majority of anything else, for almost no computational cost. It is why it is everywhere: in every Ethernet frame crossing your office, in ZIP archives, in PNG images, in gzip.

But note what it does not do. It detects. It does not correct, and it does not defend against anyone deliberately altering a file — working out how to change data while keeping the CRC the same is straightforward. CRC is for accidents.

Level 3: cryptographic hashes — a real fingerprint

A cryptographic hash such as SHA-256 also reduces any amount of data to a short fixed-length value — 64 hexadecimal characters, regardless of whether you fed it one word or a hundred gigabytes. The difference is the guarantees.

The key property is the avalanche effect: change a single bit anywhere in the input and roughly half of the output bits change, unpredictably. Two files that differ by one comma have hashes with no visible relationship whatsoever. And unlike CRC, hashes are designed so that deliberately constructing a second file with the same fingerprint is computationally infeasible.

That is why hashes underpin so much:

• Verifying downloads. The published hash tells you the file you received is byte-for-byte the file that was published — not merely undamaged, but unaltered.
• Version control. Git names every file and commit by its hash, which is what makes a repository’s history tamper-evident.
• Deduplication. Backup systems hash every block; identical hashes mean identical data, so it is stored once.

Two footnotes worth knowing. Older hashes — MD5 and SHA-1 — have been broken in the sense that collisions can now be deliberately manufactured, so they are unfit for anything security-related, though still perfectly serviceable for spotting accidental corruption. And hashing passwords is a different job again: a plain SHA-256 is far too fast for that, which is why password storage uses deliberately slow, salted schemes like bcrypt or Argon2 instead.

The leap: from detecting to repairing

Everything so far only raises its hand and says this is wrong. Useful, but if the only copy is damaged, knowing is cold comfort. Correction requires storing genuinely redundant information — enough that the missing pieces can be reconstructed rather than merely missed.

Hamming codes, devised by Richard Hamming in 1950, were the first practical answer. By overlapping several parity bits so that each data bit is covered by a different combination of them, the pattern of failed checks doesn’t just say that something broke — it points directly at which bit broke. Flip it back and the data is whole.

Reed–Solomon codes go further, working on whole symbols rather than single bits, which makes them superb against clustered damage. They are what lets a scratched CD play perfectly and a torn QR code still scan — we pulled that apart in detail here.

Level 4: ECC — correction you never see

In servers, this becomes ECC memory: 72 bits stored for every 64 bits of data, enough to correct any single flipped bit invisibly and to detect a double flip and halt rather than proceed on bad data.

This matters more than it first appears. Memory sits upstream of everything. If a bit flips in RAM before a file is written, the drive dutifully stores the corrupted version, computes a perfectly valid checksum over it, and every integrity check from that moment on will confirm the wrong data is intact. This is exactly why ECC is strongly recommended for any machine whose job is to hold or verify data — a file server, a NAS, a backup target.

Your drives are doing this too, invisibly. Every hard disk and SSD stores error-correcting codes alongside each sector and quietly repairs minor damage on every read. That is why a failing drive tends to return a read error rather than a page of garbage: its internal correction gave up honestly instead of guessing.

Level 5: across drives — RAID parity

Scale the idea up from bits to whole disks and you get RAID. Write parity across several drives — the same algebra as a parity bit, applied to entire blocks — and any one drive can die without losing anything; its contents are recomputed from the others.

Which leads to the single most important sentence in this article: RAID is not a backup. It protects against precisely one failure mode, a drive dying. It offers nothing at all against deletion, ransomware, saving a bad file over a good one, fire, theft, or the RAID controller itself failing — and in every one of those cases, the redundancy faithfully replicates the disaster across all your disks in real time. RAID buys uptime through a hardware fault. Backup buys recovery from a mistake. They are different products.

The gap nobody mentions

Here is the part that surprises people: your filesystem probably isn’t checking your files.

The traditional filesystems most computers run — NTFS on Windows, ext4 on Linux — checksum their own internal bookkeeping so the filesystem structure survives a crash, but they generally do not checksum the contents of your files. If a byte inside a document quietly changes on disk, nothing in that stack is positioned to notice.

Newer filesystems close the gap. ZFS and Btrfs store a checksum for every block of data and verify it on every single read. If a block fails its check and a redundant copy exists, they repair it transparently and log what happened. They also support scrubbing: periodically reading every block on the whole pool to find rot early, while a good copy still exists to rebuild from. That last point is the entire game — corruption discovered on a scheduled Sunday scrub is a non-event; the same corruption discovered during a restore is a very bad day.

Common questions