About

CRC-32 (Cyclic Redundancy Check, 32-bit) is a non-cryptographic hash function standardized in IEEE 802.3 and used in Ethernet, ZIP, PNG, and MPEG-2 for error detection. The algorithm divides input data by the generator polynomial G(x) of degree 32 and returns the remainder as an 8-character hexadecimal fingerprint. A single flipped bit in transit changes the checksum entirely. Relying on manual byte comparison for file integrity is error-prone and impractical beyond trivial sizes. This tool computes CRC-32 using the reflected polynomial 0xEDB88320 with a precomputed 256-entry lookup table, matching the output of crc32() in zlib, Python's binascii, and PHP.

Limitation: CRC-32 detects accidental corruption. It is not a cryptographic hash. Do not use it for tamper-proofing or password storage. Collision probability is approximately 1 in 4.29 × 10⁹ for random data. For files, the tool reads raw binary via the File API, producing identical results to command-line utilities like crc32 on Linux. Text mode encodes input as UTF-8 before hashing.

Formulas

CRC-32 treats the input byte stream as a polynomial over GF(2) and computes the remainder modulo the generator polynomial. The reflected implementation used here processes bits LSB-first with the reversed polynomial:

P_rev = 0xEDB88320

Lookup table generation for each index i from 0 to 255:

T[i] = reflect(i, 8 bits, P_rev)

For each byte b of input data, the running CRC register R is updated:

R ← T[(R ⊕ b) ∧ 0xFF] ⊕ (R >>> 8)

Initial value: R₀ = 0xFFFFFFFF. Final XOR: CRC = R ⊕ 0xFFFFFFFF. The result is a 32-bit unsigned integer, displayed as 8 uppercase hexadecimal digits.

Where: P_rev = reversed generator polynomial, T = precomputed lookup table (256 entries), R = CRC register, b = current input byte, ⊕ = bitwise XOR, >>> = unsigned right shift, ∧ = bitwise AND.

Reference Data

Format / Protocol	Uses CRC-32	Polynomial	Bit Width	Notes
IEEE 802.3 (Ethernet)	Yes	0x04C11DB7	32	Frame Check Sequence (FCS)
ZIP / GZIP	Yes	0x04C11DB7	32	File integrity in archives
PNG	Yes	0x04C11DB7	32	Chunk CRC per spec
MPEG-2	Yes	0x04C11DB7	32	Transport stream error detection
BZIP2	Yes	0x04C11DB7	32	Block-level CRC
POSIX cksum	Variant	0x04C11DB7	32	Includes length in computation
CRC-32C (Castagnoli)	Variant	0x1EDC6F41	32	iSCSI, ext4, SSE 4.2 hardware
CRC-32/XFER	Variant	0x000000AF	32	Rarely used
CRC-16/CCITT	No (16-bit)	0x1021	16	X.25, Bluetooth
CRC-8/MAXIM	No (8-bit)	0x31	8	1-Wire bus
Adler-32	No (Adler)	N/A (sum-based)	32	zlib fast check, weaker detection
MD5	No (crypto)	N/A	128	Cryptographic, deprecated for security
SHA-256	No (crypto)	N/A	256	Cryptographic, tamper-proof
Known Test: "123456789"	Verify	0xEDB88320	32	Expected: 0xCBF43926
Known Test: "" (empty)	Verify	0xEDB88320	32	Expected: 0x00000000

Frequently Asked Questions

Character encoding is the most common cause. This tool encodes text as UTF-8 before hashing. If the other tool uses ASCII, Latin-1, or UTF-16, multi-byte characters (accented letters, emoji, CJK) will produce different byte sequences and therefore different CRC-32 values. Stick to ASCII-only input when cross-verifying. The canonical test vector is the string "123456789" which must produce 0xCBF43926 under the standard IEEE polynomial.

CRC-32 detects all single-bit errors, all double-bit errors, any odd number of bit errors, and any burst error of length 32 bits or fewer. For random error patterns longer than 32 bits, the probability of an undetected error is approximately 1 in 2³² (2.33 × 10⁻¹⁰). It will NOT detect intentional tampering by an adversary who can recalculate the checksum.

Only against accidental corruption during transfer. An attacker can trivially craft a malicious file with the same CRC-32 as the original. For tamper-proof verification, use SHA-256 or SHA-3. CRC-32 is useful for quick sanity checks (e.g., confirming a download completed without network errors) but must never replace cryptographic hashes in security contexts.

Text mode converts the input string to a UTF-8 byte array using TextEncoder, then computes CRC-32 on those bytes. File mode reads the raw binary content of the file via FileReader.readAsArrayBuffer, preserving every byte exactly as stored on disk. This means file mode produces the same result as command-line tools like crc32, python3 -c "import binascii; print(hex(binascii.crc32(open('file','rb').read())))", or 7-Zip's CRC column.

They represent the same mathematical polynomial G(x) = x³² + x²⁶ + x²³ + x²² + ... + x + 1. The value 0x04C11DB7 is the MSB-first (normal) representation. The value 0xEDB88320 is the bit-reversed (reflected) form, which is computationally simpler on little-endian CPUs because it processes bits LSB-first without an extra reflect step. Both produce identical final checksums.

The tool processes files in chunks of 2 MB to prevent browser memory exhaustion and UI freezing. Files up to several hundred megabytes can be processed, limited only by available browser memory for the ArrayBuffer. A progress bar indicates completion percentage. For files exceeding 1 GB, command-line tools are recommended.