error detection · ZIP/gzip/PNG · non-cryptographic
Cyclic Redundancy Check — fast error-detection codes used in ZIP, gzip, PNG, ethernet, SATA. Detects accidental changes but not malicious tampering. Pure JavaScript.
CRC-32 (Poly 0xEDB88320), CRC-32C (Castagnoli), or CRC-16 (0x1021).Input text box — the checksum recalculates on every keystroke.0x followed by 8 hex digits (4 for CRC-16).Copy to put the checksum on your clipboard, ready to paste into a build script or manifest.Clear to empty the input and start over.ZIP entries, gzip footers, and PNG chunks all store a CRC-32. Compute one here and compare it against the value embedded in the file to confirm it survived transfer intact.
Tools like unzip and gzip -t report CRC mismatches. Reproduce the expected checksum yourself to understand exactly which data changed.
CRCs are built to catch flipped bits, dropped bytes, and transmission noise — a quick, cheap guard for logs, frames, and payloads that don't need cryptographic strength.
CRC-16 with the 0x1021 polynomial and CRC-32C (Castagnoli) appear across embedded, storage, and network protocols — reproduce documented values to debug handshakes.
Castagnoli runs as a single SSE4.2 crc32 instruction on x86_64, and is used by iSCSI, SCTP, and ext4 metadata checksums.
Everything runs in your browser. Nothing is uploaded, logged, or sent to a server — safe for proprietary payloads and pre-release data.
A Cyclic Redundancy Check is an error-detection code. It treats your data as one long polynomial and divides it by a fixed polynomial, producing a short remainder — the checksum. It reliably flags accidental changes.
No. A CRC is designed only to detect accidental corruption, not to resist tampering. It has no security strength and collisions are easy to engineer. For integrity against malicious changes, use SHA-256 (or a keyed MAC).
They use different polynomials. CRC-32 uses 0xEDB88320 (ZIP, gzip, PNG), while CRC-32C uses the Castagnoli polynomial 0x1EDC6F41 (reflected 0x82F63B78) and is hardware-accelerated on x86_64. They produce different values for the same input.
CRC variants differ in four parameters: the polynomial, initial value, input/output reflection, and final XOR. If any one differs, the result differs. Make sure you've selected the same variant — for example CRC-16 (0x1021) here uses init 0xFFFF with no reflection.
The result is the checksum in hexadecimal with a 0x prefix. A 32-bit checksum shows 8 hex digits and a 16-bit checksum shows 4, zero-padded on the left.
No. An attacker can recompute a valid CRC after modifying data, and CRC-32 offers no authenticity or collision resistance. Treat it as a corruption detector, never as a security mechanism.
Never. All computation happens locally in JavaScript. Your input is not sent to, stored on, or logged by any server.