CRC32: the ZIP integrity checksum
CRC32 (Cyclic Redundancy Check, 32-bit) is the integrity checksum the ZIP format stores for every entry. It is a fixed-size value computed over the entry's uncompressed data and recorded in both the local file header and the central directory, so an extractor can recompute it after decompression and compare. A match means the bytes survived intact; a mismatch means they did not — the classic bad CRC error.
Zipping a file applies compression, but CRC32 is calculated on the original data before compression, not on the DEFLATE output. When you extract, the tool decompresses the stream back to the original bytes, recomputes CRC32 over those bytes, and checks it against the value stored in the archive. That round trip is what catches corruption introduced anywhere along the way: a truncated download, a flaky disk sector, a partial transfer. You can see where this value lives by reading about the central directory, which carries the authoritative copy per entry.
How CRC32 is computed
CRC32 is a polynomial division performed over the data bytes, treating the input as one long binary number and dividing it by a fixed generator polynomial. ZIP uses the standard CRC-32 algorithm (also known as CRC-32/ISO-HDLC): generator polynomial 0x04C11DB7 in normal form (equivalently 0xEDB88320 reflected), an initial value of 0xFFFFFFFF, reflected input and output, and a final XOR of 0xFFFFFFFF. The result is a single 32-bit (4-byte) number. Because the math is deterministic and keyless, anyone can reproduce it — there is no secret involved, only the well-known polynomial and a straightforward bit-shifting algorithm.
A 32-bit checksum yields 2^32 (about 4.3 billion) possible values. CRC32 is mathematically guaranteed to detect all single-bit errors and all common burst errors — any burst of up to 32 consecutive corrupted bits is guaranteed to be detected, which is a property of any 32-bit CRC. This is why it works so well for accidental corruption but, as below, says nothing about deliberate tampering.
Where ZIP stores CRC32
Each entry's CRC32 appears in two places inside the archive. The local file header (immediately before that entry's compressed data) carries it, and so does the entry's record in the central directory at the end of the file. For streamed writes where the size and CRC are not yet known when the local header is written, the ZIP spec allows the header to hold zeros and the real values to follow the data in a trailing data descriptor. The central directory is the authoritative copy extractors trust.
At extraction, the tool reads the stored CRC32, decompresses the entry, recomputes CRC32 over the decompressed bytes, and compares. If they differ, the entry is flagged as corrupt and extraction aborts for that file. This verification runs over the uncompressed data regardless of whether the entry was stored, deflated, or otherwise compressed — the compression method is separate from the checksum.
What 'bad CRC' actually means
A CRC error is an integrity error, not a security event. It signals that the bytes the tool decompressed do not hash to the value recorded when the archive was created, which almost always points to accidental damage: the file was cut off mid-download, written to a failing drive, or mangled by a transfer that wasn't 8-bit clean. Retransferring or re-downloading the archive usually fixes it. It is a signal worth trusting for this purpose, because the probability of random corruption landing on a matching 32-bit CRC is tiny.
CRC32 is not cryptographic
This is the boundary that matters: CRC32 provides no protection against intentional tampering. It has no secret key, and it is a linear function, which means an attacker who changes the data can simply recompute the matching CRC32 and substitute it. The modified archive will verify cleanly. CRC32 was designed to detect accidental, random errors (transmission noise, bit rot), not adversarial ones. Treating a passing CRC as evidence the archive is authentic or unmodified-by-an-attacker is a category error.
For authenticity and tamper-resistance you need cryptography on top of the archive: digital signatures such as the META-INF signatures on signed JARs and APKs, or authenticated encryption. ZIP's own WinZip AES extension (AE-1/AE-2) provides authentication via AES in CTR mode combined with an HMAC-SHA1 tag — not AES-GCM — and it authenticates the encrypted payload rather than replacing CRC32's role for unencrypted entries. A plain CRC32 cannot substitute for any of these. For the broader distinction between integrity and the privacy model of in-browser viewing, see security and privacy.
Frequently asked questions
What is CRC32?
CRC32 (Cyclic Redundancy Check, 32-bit) is a non-cryptographic checksum produced by dividing the data by a fixed polynomial (0x04C11DB7) and taking the 32-bit remainder. In ZIP archives it is computed over each entry's uncompressed bytes and stored in the local header and central directory so extractors can verify the data survived intact.
What does a CRC error mean in a zip?
It means the bytes the tool decompressed do not match the CRC32 stored when the archive was created. This is an integrity error pointing to accidental corruption — a truncated download, a failing disk, or a damaged transfer. Re-downloading or re-copying the archive typically resolves it.
Is CRC32 secure?
No. CRC32 detects accidental corruption reliably but provides zero protection against deliberate tampering. It is keyless and linear, so an attacker can modify the data and recompute a matching CRC32. For authenticity or tamper-resistance you need digital signatures (like signed JAR/APK META-INF signatures) or authenticated encryption such as ZIP's WinZip AES extension (AES-CTR plus HMAC-SHA1).
Why does my zip say 'bad CRC'?
'Bad CRC' is the message extractors print when the recomputed CRC32 of a decompressed entry differs from the value recorded in the archive. It indicates the file's contents changed after archiving — most often from a partial download or storage fault. Re-acquire the archive; if the error persists from a fresh copy, the source archive itself is damaged.
Is CRC32 computed on compressed or uncompressed data?
On uncompressed data. ZIP records the CRC32 of the original file contents, not of the DEFLATE output. At extraction the tool decompresses the stream, recomputes CRC32 over the original bytes, and compares — which is why CRC catches corruption in either the compressed stream or the decompression process.