CRC Checksum Calculator (CRC-8/16/32/64)

A Cyclic Redundancy Check treats the input message as a large binary polynomial and divides it by a fixed generator polynomial; the remainder is the checksum. CRCs are designed to detect accidental errors in transmission or storage — bit flips, dropped bytes, or transposed runs — and they do so very efficiently. Cryptographic hashes like SHA-256 solve a different problem: they are collision-resistant and meant to resist adversarial tampering. CRCs are fast and mathematically predictable but trivially easy to forge, so they should never be used for security purposes.

Different standards bodies and vendors picked different generator polynomials, initial register values, bit reflection settings, and final XOR values to suit their error-detection needs. Ethernet, ZIP, and PNG all agreed on CRC-32 (IEEE 802.3), while industrial protocols like MODBUS, USB, and XMODEM standardized on their own CRC-16 flavors. Two variants with the same bit width will produce completely different checksums for the same input if any parameter differs, which is why picking the exact variant that matches your target system is essential.

Reflected (sometimes called reversed) variants process each byte least-significant-bit first and mirror the final register bit-for-bit before applying the output XOR. Non-reflected variants process bits in most-significant order. This choice originated in hardware designs where shifting a register in one direction was cheaper than the other. Two CRCs with the same polynomial but different reflection settings are not compatible — CRC-32 and CRC-32/BZIP2 share the same 0x04C11DB7 polynomial yet produce entirely different values.

CRC-32C, published by Guy Castagnoli in 1993, uses polynomial 0x1EDC6F41 instead of 0x04C11DB7. Its error-detection properties are mathematically superior for short payloads, and modern x86 processors implement it directly in a single CRC32 instruction. It is the checksum used by iSCSI, SCTP, ext4 metadata, Btrfs, and Google's gRPC framing layer. When high throughput and strong detection both matter, systems increasingly prefer CRC-32C over the classic Ethernet CRC.

No error-detection code catches everything. An n-bit CRC guarantees detection of all burst errors up to n bits long and all single-bit errors, but roughly 1 in 2^n random corruptions will slip through undetected. For CRC-32 that is about 1 in 4.3 billion — excellent for ordinary file and frame integrity. For very large files or long-haul storage, CRC-64 extends that bound to roughly 1 in 1.8 × 10^19. Adversarial modification is a different story: attackers can always adjust a message so its CRC matches a chosen value, which is why checksums must never replace digital signatures for authentication.