About

CRC-16 (Cyclic Redundancy Check, 16-bit) is a family of error-detecting codes used in digital networks, storage devices, and industrial protocols (MODBUS, DNP3, USB). The generator polynomial G(x) of degree 16 divides the input message polynomial over GF(2), producing a 16-bit remainder. Incorrect polynomial selection or init-value mismatch silently passes corrupted frames in SCADA and PLC communications. This tool computes CRC-16 using precomputed 256-entry lookup tables for each variant, matching bit-reflection and XOR-out parameters defined by the catalogue maintained by Greg Cook. It approximates no values; every variant reproduces reference test vectors for the ASCII string "123456789".

Note: CRC-16 detects all single-bit, double-bit, and odd-count bit errors within its Hamming distance, but it is not a cryptographic hash. Do not use it for authentication or tamper detection. For files, processing is offloaded to a background thread to avoid UI blocking.

Formulas

CRC-16 treats the input byte sequence as a polynomial M(x) over GF(2) and computes the remainder after division by a generator polynomial G(x) of degree 16.

CRC = (M(x) ⋅ x¹⁶) mod G(x) ⊕ XorOut

For table-driven computation, a 256-entry lookup table T is precomputed. For each byte b in the message, the register R is updated:

R ← (R ≪≪ 8) ⊕ T[(R ≫≫ 8) ⊕ b]

When RefIn is TRUE, each input byte is bit-reversed before processing. When RefOut is TRUE, the final register is bit-reversed before XOR. The reflected variant uses a mirrored polynomial and processes from the low byte:

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

Where M(x) = message polynomial, G(x) = generator polynomial, R = CRC register (initialized to Init), T = lookup table, b = current byte, ⊕ = bitwise XOR, XorOut = final XOR mask.

Reference Data

Variant	Polynomial	Init	RefIn	RefOut	XorOut	Check ("123456789")	Common Use
CRC-16/ARC	0x8005	0x0000	true	true	0x0000	0xBB3D	ARC, LHA
CRC-16/CCITT-FALSE	0x1021	0xFFFF	false	false	0x0000	0x29B1	Bluetooth, PPP
CRC-16/XMODEM	0x1021	0x0000	false	false	0x0000	0x31C3	XMODEM, ZMODEM
CRC-16/MODBUS	0x8005	0xFFFF	true	true	0x0000	0x4B37	MODBUS RTU
CRC-16/USB	0x8005	0xFFFF	true	true	0xFFFF	0xB4C8	USB Token/Data
CRC-16/BUYPASS	0x8005	0x0000	false	false	0x0000	0xFEE8	Verifone, Buypass
CRC-16/CDMA2000	0xC867	0xFFFF	false	false	0x0000	0x4C06	CDMA2000 3GPP2
CRC-16/DNP	0x3D65	0x0000	true	true	0xFFFF	0xEA82	DNP3 SCADA
CRC-16/MAXIM	0x8005	0x0000	true	true	0xFFFF	0x44C2	1-Wire Maxim
CRC-16/KERMIT	0x1021	0x0000	true	true	0x0000	0x2189	Kermit Protocol
CRC-16/AUG-CCITT	0x1021	0x1D0F	false	false	0x0000	0xE5CC	SPI, I²C
CRC-16/GENIBUS	0x1021	0xFFFF	false	false	0xFFFF	0xD64E	EPC Gen 2 RFID

Frequently Asked Questions

Each CRC-16 variant is parameterized by five values: the generator polynomial, initial register value, input reflection flag, output reflection flag, and final XOR mask. Even variants sharing the same polynomial (e.g., CRC-16/ARC and CRC-16/MODBUS both use 0x8005) differ in their init value (0x0000 vs 0xFFFF), producing entirely different remainders. Always verify which variant your protocol specification requires.

Reflection reverses the bit order within each byte (RefIn) or the final 16-bit register (RefOut). Protocols like MODBUS RTU transmit LSB first, so they use reflected CRC. Protocols like XMODEM transmit MSB first and use non-reflected CRC. Using the wrong reflection setting causes valid frames to fail verification at the receiver, even though the polynomial is correct.

CRC-16 guarantees detection of all single-bit errors, all double-bit errors (for messages shorter than the polynomial period), all odd-count bit errors, and any burst error of length ≤ 16 bits. It does not detect all errors in bursts longer than 16 bits; the probability of missing such an error is approximately 1/65535 ≈ 0.0015%. For cryptographic integrity, use SHA-256 or similar.

Use CRC-16/MODBUS: polynomial 0x8005, init 0xFFFF, RefIn = TRUE, RefOut = TRUE, XorOut = 0x0000. The check value for the ASCII string "123456789" must equal 0x4B37. Verify against this test vector before deploying to production PLCs.

Yes. CRC operates on raw bytes, not characters. The string "café" encoded in UTF-8 produces 5 bytes (the "é" maps to 0xC3 0xA9), while ISO-8859-1 produces 4 bytes (0xE9). This tool uses UTF-8 encoding via the TextEncoder API. If your protocol uses a different encoding, hash the file directly as binary to avoid mismatches.

The lookup table approach precomputes all 256 possible byte-XOR results, reducing the inner loop from 8 conditional branches per byte to a single table lookup, shift, and XOR. This yields roughly 8× throughput improvement. For a 10 MB file, bitwise CRC-16 may take ~200 ms while table-driven completes in ~25 ms on modern hardware. This tool uses the table-driven method exclusively.