Connect via MCP →

Enter Calculation

Formula

Advertisement

Results

CRC Checksum (hex)
0x29B1
16-bit checksum
Decimal value 10,673
Width 16 bits
Bytes processed 9

What is a CRC checksum?

A Cyclic Redundancy Check (CRC) is an error-detecting code widely used in networking, storage, and file formats (Ethernet, ZIP, PNG, Modbus, USB and more). It treats your data as a long binary number and divides it by a fixed generator polynomial using carry-less binary arithmetic (GF(2), where addition and subtraction are both XOR). The remainder of that division is the CRC. If even a single bit of the message changes, the remainder almost always changes too, which is what makes CRCs excellent at catching transmission and storage errors.

Block diagram of a message split into data plus an appended CRC checksum field
A CRC appends a short check value to the data so errors can be detected.

How to use this calculator

Type any ASCII text into the input box, pick the CRC variant you need, and read the result. The tool reports the checksum in both hexadecimal and decimal, along with the bit width and the number of bytes processed. Three common variants are supported:

CRC-8 — polynomial \(\mathtt{0x07}\), initial value \(\mathtt{0x00}\).
CRC-16/CCITT-FALSE — polynomial \(\mathtt{0x1021}\), initial value \(\mathtt{0xFFFF}\), no reflection.
CRC-32 (IEEE 802.3) — reflected polynomial \(\mathtt{0xEDB88320}\), initial \(\mathtt{0xFFFFFFFF}\), final XOR \(\mathtt{0xFFFFFFFF}\). This is the variant used by ZIP, gzip, and Ethernet.

$$\text{CRC} = \mathrm{XorOut} \oplus \bigoplus_{b \in \text{Message bytes}} \mathrm{Update}_{\text{poly}}(\text{crc}, b)$$

where (CRC-16/CCITT-FALSE):

$$\left\{ \begin{aligned} \text{poly} &= \mathtt{0x1021} \\ \mathrm{init} &= \mathtt{0xFFFF} \\ \mathrm{XorOut} &= \mathtt{0x0000} \\ \text{width} &= 16 \text{ bits (MSB-first, no reflection)} \end{aligned} \right.$$

The formula explained

Conceptually, the message \(M(x)\) is multiplied by \(x^n\) (where \(n\) is the degree of the generator) and divided by \(G(x)\). In practice we use a register that we shift one bit at a time, XOR-ing in the polynomial whenever the leading bit is 1. Reflected variants (like CRC-32) process bits least-significant-first and shift right instead of left.

$$\text{CRC}_{16} = \bigoplus_{b \in \text{Message bytes}} \mathrm{Update}(\text{crc}, b)$$$$\text{where}\quad \left\{ \begin{aligned} \mathrm{init} &= \mathtt{0xFFFF} \\ \text{poly} &= \mathtt{0x1021} \\ \text{step} &: \text{crc} \leftarrow \big(\text{crc} \ll 1\big) \oplus (\text{MSB}?\,\text{poly}:0) \\ \text{width} &= 16 \text{ bits, MSB-first} \end{aligned} \right.$$$$\text{CRC}_{8} = \bigoplus_{b \in \text{Message bytes}} \mathrm{Update}(\text{crc}, b)$$$$\text{where}\quad \left\{ \begin{aligned} \mathrm{init} &= \mathtt{0x00} \\ \text{poly} &= \mathtt{0x07} \\ \text{step} &: \text{crc} \leftarrow \big(\text{crc} \ll 1\big) \oplus (\text{MSB}?\,\text{poly}:0) \\ \text{width} &= 8 \text{ bits, MSB-first} \end{aligned} \right.$$$$\text{CRC}_{32} = \mathtt{0xFFFFFFFF} \oplus \bigoplus_{b \in \text{Message bytes}} \mathrm{Update}(\text{crc}, b)$$$$\text{where}\quad \left\{ \begin{aligned} \mathrm{init} &= \mathtt{0xFFFFFFFF} \\ \text{poly} &= \mathtt{0xEDB88320}\ (\text{reflected}) \\ \text{step} &: \text{crc} \leftarrow \big(\text{crc} \gg 1\big) \oplus (\text{LSB}?\,\text{poly}:0) \\ \text{width} &= 32 \text{ bits, LSB-first} \end{aligned} \right.$$
Polynomial long division of message bits by the generator polynomial over GF(2) using XOR steps
CRC is the remainder of binary polynomial division (XOR) of the message by the generator \(G(x)\).

Worked example

For the classic check string 123456789: CRC-16/CCITT-FALSE returns 0x29B1 (decimal \(10673\)), and CRC-32/IEEE returns 0xCBF43926 (decimal \(3421780262\)). These are the standard "check" values published in CRC reference catalogs, so you can verify any implementation against them.

FAQ

Why does my result differ from another tool? CRC variants differ in polynomial, initial value, bit reflection, and final XOR. Make sure you are comparing the exact same variant.

Is CRC a secure hash? No. CRC detects accidental errors but is trivial to forge intentionally. Use SHA-256 or similar for security.

What encoding is used? Each character is taken as its 8-bit ASCII/Latin-1 byte value before the CRC is computed.

Last updated: