What is CRC32 actually used for?

The commonest encounter is an archive that refuses to extract, with a message naming a CRC and explaining nothing else. None of the places those eight characters turn up is a cryptographic decision anybody made recently: an archive format from the 1980s reserved four bytes for one, a network controller computes one on every frame whether anybody asked or not, somebody catalogued a folder of disc images decades ago and the values still check out. It is the oldest integrity check you meet in an ordinary week, and for its own narrow job nothing has replaced it in fifty years.

CRC32 is an error-detecting code. Its job is to answer one question — did these exact bytes survive this one step — immediately, in hardware, so a machine can throw away a damaged frame and ask for it again without troubling anybody. It is not a fingerprint, it does not identify a file, and it was never built to resist anybody. Cyclic redundancy checks are a defense against physics.

This page is about where that job actually gets done, and why the answer matters when you are trying to verify something. If what you need is the mechanics of producing one and matching it against a published value, calculating a CRC32 on a Mac covers the bases, the leading zeros and the comparison. If you are choosing an algorithm for yourself rather than matching somebody else's, the decision tree will send you elsewhere.

The job it was designed to do

Detection and correction are different ambitions, and CRC32 only does the first. It will tell you that something in this block is wrong; it will not tell you what, or where, and it cannot put it back. Correcting codes exist — Reed–Solomon on an optical disc, LDPC on a radio link, the extra chips in ECC memory — and they all cost considerably more room. A CRC is the cheapest useful answer: spend four bytes, learn whether to discard the block, and let the layer above arrange a retry.

What makes that cheap answer trustworthy is that it was designed around a specific opponent. Hardware failures have a shape: a marginal cable flips a run of adjacent bits, a scratch takes out a contiguous region, noise on a radio link arrives in bursts. A cyclic redundancy check is built around exactly that shape, which is why it can promise certainty for whole classes of error rather than a probability — the arithmetic behind that promise is in the guide to computing one.

And because detection is all it does, a CRC is disposable. That turns out to be the single most important thing to understand about it.

Where CRC32 is already running

You do not have to go looking for it. Every one of these is happening on an ordinary Mac, on an ordinary afternoon, without anybody asking.

• Ethernet and Wi-Fi frames. Every frame carries a 32-bit frame check sequence. A receiver that does not like the number drops the frame in silence and something higher up notices the gap. Scope: one frame, in flight, for microseconds.
• Storage links. SATA and similar interfaces check a CRC on data in transit, which catches a failing cable or connector rather than a failing platter.
• ZIP archives. One CRC32 per member, computed over that file's uncompressed contents when the archive was built and checked again as you extract. That is the source of nearly every CRC message a normal person ever sees — hashing a ZIP archive pulls the internal and external checks apart.
• gzip streams. A CRC32 of the uncompressed data sits in the trailer, at the end, which is why gunzip can only tell you a file was corrupt after it has finished decompressing it.
• PNG images. One CRC32 per chunk, so a decoder can identify a damaged section instead of abandoning the whole image. That is why a damaged PNG often renders as far as the corruption and no further.
• Broadcast and telemetry formats. MPEG-2 transport streams CRC their tables, because a receiver cannot ask a satellite for a retransmission; it can only discard a bad copy and wait for the next one.
• SFV lists and preservation databases. Eight characters per file, a convention inherited from Usenet that survives in ROM and disc-image catalogs because the values were recorded decades ago and are still correct.
• Filesystem and storage metadata. Btrfs, ext4 and iSCSI checksum their own structures, though usually with CRC-32C — a different polynomial producing completely different eight characters from the same bytes.

Add those up and a 1 GB download has been CRC-checked something close to a million times before it reaches your disk: roughly 700,000 Ethernet frames on the way in, the storage link on the way down, then every member of the archive and every chunk of every image inside it. Which raises the obvious question.

Why all those passing checks prove nothing about your file

If a file survived a million integrity checks on the way to you, why does every serious publisher still print a SHA-256 beside the download? Because of two structural facts about how those checks work.

Scope. Each CRC covers one span and no more — one frame, one chunk, one archive member. None of them covers the file as a whole, and none of them has any opinion about the relationship between the file you received and the file the publisher meant to send. They also leave gaps: between checks the bytes sit in memory, in caches and on disk, outside everybody's coverage.

Moment. A CRC is not carried end to end; it is regenerated by whoever last handled the bytes. Every hop that touches a frame recomputes the frame check sequence. A proxy that serves you a different file serves it with immaculate CRCs all the way down. A build machine that packaged the wrong artifact wrote a perfectly valid CRC32 into the ZIP. The value always describes the bytes as they were at the last handler, which is precisely the wrong question when the last handler is the thing you are unsure about.

A publisher's SHA-256 is the opposite arrangement on both counts: one value, covering the entire file, computed once at the source and never regenerated in transit. That is what makes it comparable weeks later from a different network — what a checksum actually proves sets out the conditions, and verifying a download is the practical version.

None of which makes the CRCs useless. They are the reason your download arrives intact nearly every time, and the reason that when a SHA-256 does not match, the cause is overwhelmingly a truncated transfer rather than anything sinister. Working through a mismatch starts from that assumption for good reason.

Why new formats still choose it

Not to save you time. On a Mac, SHA-256 already arrives faster than the disk can feed it, so picking CRC32 for a file you hash yourself buys nothing you would notice. The three reasons it keeps its place are about constraints a file-level digest never has to meet.

• It fits in four bytes. A frame trailer, a chunk header, a per-record field — these have room for 32 bits and not 256. There is no useful four-byte cryptographic hash to reach for instead, because four bytes is not enough space to be unforgeable.
• It costs almost nothing in silicon. A CRC is a shift register and a handful of XOR gates. It runs at line rate inside a network controller with no processor involved at all, which is what allows a check on every frame rather than on every file.
• It composes. This is the property people forget. Given the CRCs of two pieces and the length of the second, you can calculate the CRC of the two joined together without re-reading either — zlib exposes exactly that operation — and you can update a CRC after a small edit. A SHA-256 has to be recomputed from the first byte. For a storage system checksumming blocks and wanting a value for the whole object, that is worth a great deal.

A checksum, a CRC and a hash are three things

One word gets used for all three, which is most of why this is confusing.

That last row is the whole distinction, and it is not a flaw that somebody should fix. The arithmetic is linear on purpose: that linearity is what lets a CRC promise certainty for whole classes of error rather than a probability, and what keeps the sums cheap enough for a shift register. The same linearity means four bytes appended to a file will set its CRC32 to any value you choose, with no searching and no special hardware. Ask a CRC whether a cable is behaving and it is excellent. Ask it whether a supplier is honest and the question is meaningless.

Which leaves a narrow but real use for a CRC32 you compute yourself. A mismatch is conclusive — those two files are definitely different, and eight characters told you so. A match is good evidence against accidental damage, because random corruption gets past it only about once in 4.3 billion, and no evidence whatsoever against somebody who changed the file on purpose. Record a SHA-256 as well where you have the choice; Rocket Hash produces both from a single read of the file, so keeping the stronger value costs nothing but the room to write it down.

Troubleshooting

Unzipping stops with a CRC error

The bytes that came out of the archive do not match the CRC32 recorded when the archive was built, so that member is damaged. It will not tell you where the damage is, and there is nothing to repair — the archive is the only copy of the information. Check the file size against the download page first, since a truncated transfer is the usual explanation, then fetch it again. Verifying the archive against a published checksum before unpacking turns a ten-minute mystery into a ten-second answer.

An image or video opens with a CRC warning

A per-chunk check failed and the decoder is telling you it carried on anyway. What you are looking at is a genuinely corrupt file being rendered as best the software can manage, which is why the image may be half grey or the video may glitch at one point and recover. No amount of re-opening will change it; go back to the source copy.

An SFV file says one file failed

An SFV is a plain list of filenames and eight-character CRC32 values, each one covering a whole file exactly as it sat on disk when the list was made. A failure therefore means that one file differs from the original and the rest of the set is fine, so re-fetch only the file that was named. If the whole list fails, suspect the list rather than the files — usually it was made from a different release.

Something only reports a CRC32 and I want more

You cannot derive a stronger digest from a weaker one; the four bytes do not contain the information. Compute what you need from the same bytes yourself and keep both values — theirs to satisfy the comparison they offered, yours for your own records. Getting both out of a file is the Files tool's job — one read of the disk yields every algorithm, so the eight characters and the 64 provably describe the same bytes. The CRC32 calculator here covers a string rather than a file.

Every CRC passes and the file still does not work

Then the file is intact and wrong, which are compatible conditions. Intact means no byte was damaged in transit; it says nothing about whether you were handed the version for your architecture, the release you meant to download, or a build that was broken before anybody packaged it. Check what you were supposed to receive rather than whether you received it faithfully.

Frequently asked questions

Is CRC32 still used today?

Constantly, and almost always invisibly. Every Ethernet and Wi-Fi frame carries one, every ZIP member and PNG chunk has one recorded inside the file, gzip puts one in its trailer, and broadcast formats and filesystem metadata rely on them. It has been superseded for anything involving trust, but for detecting accidental damage in hardware it has never been replaced.

Is CRC32 a hash function?

In the loose sense, yes — it maps input of any length to a fixed 32-bit value, and it is genuinely used as a hash in hash tables and lookup structures. It is not a cryptographic hash, and that is the sense people usually mean. It offers no resistance to somebody constructing a match on purpose, so it cannot stand in for SHA-256 anywhere that matters.

Why is CRC32 built into so many file formats?

Three reasons that still hold. It fits in four bytes, which is often all a header or a frame trailer can spare. It costs almost nothing in hardware — a shift register and some XOR gates — so it can run at line rate with no processor involved. And the CRCs of two pieces can be combined into the CRC of the whole without re-reading either, which a cryptographic hash cannot do.

What is the difference between CRC32 and a checksum?

A plain checksum adds the bytes up, which is why it misses anything that cancels out — swap two bytes and the sum is unchanged. CRC32 divides the data by a fixed polynomial and keeps the remainder, which catches reordering and catches bursts of adjacent flipped bits with certainty. Both are error detection; the CRC is much better at it for the same handful of bytes.

Can CRC32 detect deliberate tampering?

No, and not in a way that can be patched. The arithmetic is linear, so anyone can calculate exactly which four bytes to append to a file to give it whatever CRC32 they want — no searching, no special hardware, no cost. A CRC32 is evidence about your cable, never about the person who sent you the file. For that you want a cryptographic digest and, ideally, a signature over it.

What does a CRC error mean when extracting a ZIP file?

That the data extracted from one member does not match the CRC32 stored for it when the archive was created, so that file inside the archive is corrupt. The commonest cause by far is an incomplete download — compare the archive's size with the figure on the download page. The check cannot locate or repair the damage, so the fix is to fetch the archive again.

Is CRC32C the same as CRC32?

No. CRC-32C uses the Castagnoli polynomial rather than the one ZIP, gzip, PNG and Ethernet share, so it produces entirely different eight characters from identical input. It shows up in iSCSI, Btrfs, ext4 and other storage code. Two values from different variants will never agree, which is worth checking before assuming a file is damaged.