About

CRC-32 produces a 32-bit checksum (8 hexadecimal characters) used to detect accidental corruption in data during storage or transmission. It does not provide cryptographic security. A single flipped bit in a multi-gigabyte file changes the resulting CRC value entirely, making it effective for integrity verification in protocols like Ethernet (IEEE 802.3), PNG, ZIP, and GZIP. The algorithm uses polynomial division over GF(2) with the generator polynomial G(x) = 0xEDB88320 in reflected (LSB-first) form. This tool computes the checksum per ISO 3309 / ITU-T V.42 specification. Note: CRC-32 is not collision-resistant. Approximately 1 in 4.29 × 10⁹ chance of two random inputs sharing the same hash. Do not use it for password hashing or digital signatures.

Formulas

CRC-32 computes the remainder of polynomial division over GF(2). The reflected table-driven algorithm processes one byte at a time:

crc ← 0xFFFFFFFF

for each byte b in input:
index = (crc ⊕ b) ∧ 0xFF
crc = T[index] ⊕ (crc >>> 8)

result = crc ⊕ 0xFFFFFFFF

The lookup table T[256] is precomputed from the reflected polynomial P = 0xEDB88320:

for i = 0 to 255:
c ← i
for j = 0 to 7:
c = (c ∧ 1) ? (P ⊕ (c >>> 1)) : (c >>> 1)
T[i] = c

Where crc is the running checksum register, b is the current input byte, T is the 256-entry lookup table, P = 0xEDB88320 is the reflected polynomial of the standard CRC-32 generator 0x04C11DB7, ⊕ denotes bitwise XOR, and >>> denotes unsigned right shift. The initial value and final XOR mask are both 0xFFFFFFFF per ISO 3309.

Reference Data

Protocol / Format	CRC Variant	Polynomial (Hex)	Width	Init Value	XOR Out	Reflect
Ethernet (IEEE 802.3)	CRC-32	0x04C11DB7	32 bits	0xFFFFFFFF	0xFFFFFFFF	Yes
ZIP / GZIP	CRC-32	0x04C11DB7	32 bits	0xFFFFFFFF	0xFFFFFFFF	Yes
PNG	CRC-32	0x04C11DB7	32 bits	0xFFFFFFFF	0xFFFFFFFF	Yes
MPEG-2	CRC-32/MPEG-2	0x04C11DB7	32 bits	0xFFFFFFFF	0x00000000	No
BZIP2	CRC-32/BZIP2	0x04C11DB7	32 bits	0xFFFFFFFF	0xFFFFFFFF	No
Castagnoli (iSCSI)	CRC-32C	0x1EDC6F41	32 bits	0xFFFFFFFF	0xFFFFFFFF	Yes
POSIX cksum	CRC-32/POSIX	0x04C11DB7	32 bits	0x00000000	0xFFFFFFFF	No
JAMCRC	CRC-32/JAMCRC	0x04C11DB7	32 bits	0xFFFFFFFF	0x00000000	Yes
XFER	CRC-32/XFER	0x000000AF	32 bits	0x00000000	0x00000000	No
CRC-16 (Modbus)	CRC-16	0x8005	16 bits	0xFFFF	0x0000	Yes
CRC-8 (Dallas/Maxim)	CRC-8	0x31	8 bits	0x00	0x00	Yes
CRC-64 (ECMA-182)	CRC-64	0x42F0E1EBA9EA3693	64 bits	0x0000000000000000	0x0000000000000000	No
Known Test Vector	CRC-32 of "123456789"	0xCBF43926
Empty Input	CRC-32 of ""	0x00000000

Frequently Asked Questions

The CRC register is initialized to 0xFFFFFFFF, but since no bytes are processed, the register remains unchanged. The final XOR with 0xFFFFFFFF produces 0xFFFFFFFF ⊕ 0xFFFFFFFF = 0x00000000. This is correct behavior per the standard.

Yes. CRC-32 guarantees detection of all single-bit errors, all double-bit errors, all odd numbers of bit errors, and any burst error of length 32 bits or fewer. For burst errors longer than 32 bits, the probability of undetected error is approximately 1 in 2³² (2.33 × 10⁻¹⁰).

The normal polynomial 0x04C11DB7 processes bits MSB-first. The reflected form 0xEDB88320 is the bit-reversal of the normal form and processes bits LSB-first, which aligns with how most hardware (UART, Ethernet) transmits data. Both produce identical results when the reflect-in and reflect-out settings match.

CRC-32 detects accidental corruption effectively and is widely used in ZIP and RAR archives for this purpose. However, it is not collision-resistant. An attacker can craft a file with a matching CRC-32 in constant time using linear algebra over GF(2). For security-critical verification, use SHA-256 or SHA-3 instead.

Multiple CRC-32 variants exist (CRC-32, CRC-32C, CRC-32/MPEG-2, CRC-32/POSIX). They use different polynomials, initial values, or reflection settings. This tool implements the standard CRC-32 (ISO 3309), which is the variant used by Ethernet, ZIP, and PNG. Verify that the other tool uses the same variant. The test vector for "123456789" (ASCII) should produce 0xCBF43926.

CRC-32 operates on raw bytes, not characters. The string "ü" is 1 byte in ISO-8859-1 (0xFC) but 2 bytes in UTF-8 (0xC3 0xBC), producing different checksums. This tool encodes text as UTF-8 via the TextEncoder API, which is the modern standard. Always agree on encoding when comparing checksums.