CRC Calculator
Compute CRC-8, CRC-16/CCITT, CRC-16/Modbus, CRC-32, and CRC-32C checksums. Custom polynomial, init, reflection, and XOR parameters supported. Verify data integrity in your browser.
Algorithm
| Width | Polynomial | Init | Ref In | Ref Out | XOR Out | Check (123456789) |
|---|---|---|---|---|---|---|
| 32-bit | 0x04C11DB7 | 0xFFFFFFFF | Yes | Yes | 0xFFFFFFFF | 0xCBF43926 |
Input Data
13 bytes
CRC-32 Result
Hex
0x-13B53C30
Decimal
-330644528
Binary
0b00-10011101101010011110000110000
Byte Array
[0xEC, 0x4A, 0xC3, 0xD0]
CRC Algorithm Reference
The table below lists the parameters for every preset available in this calculator. The Check column shows the expected CRC of the ASCII string "123456789" — a standard test vector to confirm algorithm correctness.
| Algorithm | Width | Poly | Init | RefIn | RefOut | XorOut | Check | Used In |
|---|---|---|---|---|---|---|---|---|
| CRC-8 | 8 | 0x07 | 0x00 | No | No | 0x00 | 0xF4 | 1-Wire, SMBus |
| CRC-8/CDMA2000 | 8 | 0x9B | 0xFF | No | No | 0x00 | 0xDA | CDMA2000 |
| CRC-16/IBM | 16 | 0x8005 | 0x0000 | Yes | Yes | 0x0000 | 0xBB3D | USB, Bluetooth |
| CRC-16/CCITT | 16 | 0x1021 | 0xFFFF | No | No | 0x0000 | 0x29B1 | XMODEM, SD card |
| CRC-16/MODBUS | 16 | 0x8005 | 0xFFFF | Yes | Yes | 0x0000 | 0x4B37 | Modbus, industrial |
| CRC-32 | 32 | 0x04C11DB7 | 0xFFFFFFFF | Yes | Yes | 0xFFFFFFFF | 0xCBF43926 | Ethernet, ZIP, PNG |
| CRC-32C | 32 | 0x1EDC6F41 | 0xFFFFFFFF | Yes | Yes | 0xFFFFFFFF | 0xE3069283 | iSCSI, SCTP, SSE4.2 |
How CRC Computation Works
CRC is computed using polynomial arithmetic in GF(2) — a finite field where addition is XOR and multiplication is AND. The data block is treated as coefficients of a polynomial, which is then divided by the generator polynomial; the remainder is the CRC. In practice, this is implemented using a shift register and the lookup table optimization. For each byte of data, an 8-bit index into a 256-entry precomputed table is computed, and the result XORed with the shifted CRC register. This reduces the computation to one table lookup and two XOR operations per byte — efficient even on microcontrollers without hardware CRC units.
Build Table
A 256-entry lookup table is computed from the polynomial once. Each entry represents the CRC contribution of one possible byte value.
Process Bytes
For each input byte, XOR with the high or low byte of the CRC register, use the result as a table index, and XOR back the table value with the shifted register.
Finalize
Optionally reflect the output and XOR with the final XOR constant to produce the final CRC value.
CRC vs Other Checksums
A simple sum checksum (add all bytes modulo 256) is fast but misses many error patterns — for example, transposing two bytes produces the same sum. CRC catches all single-bit errors, all double-bit errors (for well-chosen polynomials), all burst errors shorter than the CRC width, and most longer burst errors. Cryptographic hashes like SHA-256 offer much stronger guarantees but at far higher computational cost. CRC is the right tool for detecting accidental data corruption in communications and storage — it is not suitable for detecting intentional tampering. For security applications where integrity must be authenticated, use HMAC-SHA-256 or similar.
Frequently Asked Questions
What is a CRC checksum?
CRC (Cyclic Redundancy Check) is an error-detecting code widely used in digital networks and storage devices to detect accidental changes to raw data. It works by treating the data as a large binary polynomial and performing polynomial division modulo a generator polynomial. The remainder of this division is the CRC value, which is appended to or transmitted alongside the data. The receiver recalculates the CRC and compares it to the received value — a mismatch indicates corruption.
What is the difference between CRC-8, CRC-16, and CRC-32?
The number indicates the bit width of the CRC output. CRC-8 produces an 8-bit (1-byte) checksum — compact but only detects single-byte errors reliably, used in SMBus and 1-wire protocols. CRC-16 produces a 16-bit (2-byte) checksum — a good balance of size and error detection, used in Modbus, XMODEM, USB, and many industrial protocols. CRC-32 produces a 32-bit (4-byte) checksum — strong error detection, used in Ethernet, ZIP files, PNG images, and gzip. Wider CRCs have lower probability of false positives.
What do the CRC parameters (polynomial, init, refIn, refOut, xorOut) mean?
Polynomial: the generator polynomial defining the CRC algorithm — different polynomials catch different error patterns. Init: the starting value of the CRC register before processing any bytes — often 0x00 or 0xFF. RefIn (Reflect Input): when true, each input byte is bit-reversed before processing — used in many industrial and Ethernet standards. RefOut (Reflect Output): when true, the final CRC register value is bit-reversed before the XOR step. XorOut: a value XORed with the CRC register as the final step — often 0x00 or 0xFFFF. Together these parameters uniquely define the algorithm variant.
Why are there multiple CRC-16 variants?
The CRC-16 family has many variants because different industries standardized different polynomial/parameter combinations before a common standard emerged. CRC-16/IBM (also called CRC-16/ARC) uses polynomial 0x8005 with reflected processing and is used in USB and Bluetooth. CRC-16/CCITT (also called CRC-CCITT or XMODEM) uses polynomial 0x1021 and was standardized by the ITU for serial communication protocols. CRC-16/MODBUS uses the same polynomial as CRC-16/IBM but starts with init=0xFFFF — widely used in industrial automation. Always verify which variant your target protocol requires.
How do I use CRC for data verification in embedded systems?
In firmware, you compute the CRC of a data block when writing or transmitting it, then store or send the CRC value alongside the data. When reading or receiving, you re-compute the CRC over the same data and compare. If they match, the data is intact. A common optimization is to compute the CRC over data + CRC together — if the combined result is a known constant (the 'residue' of the algorithm), the data is valid without a separate comparison. Lookup table implementations precompute the per-byte contribution, reducing each byte to one table lookup and one XOR operation — this is what this tool uses internally.