CRC Checksum Calculator

Quick answers

What is a CRC?

// CRC-16/MODBUS: poly=0x8005, init=0xFFFF, refin/refout=true, xorout=0x0000
// Written in the reflected form, so the polynomial appears bit-reversed as 0xA001.
function crc16Modbus(bytes) {
  let crc = 0xffff;
  for (const byte of bytes) {
    crc ^= byte;
    for (let i = 0; i < 8; i++) {
      crc = crc & 1 ? (crc >>> 1) ^ 0xa001 : crc >>> 1;
    }
  }
  return crc;
}

crc16Modbus([0x01, 0x03, 0x00, 0x00, 0x00, 0x0a]); // 0xCDC5
// On the wire Modbus RTU sends the low byte first: ... 0x0A 0xC5 0xCD

What this calculator does

Worked examples

123456789

CRC-32/ISO-HDLC = 0xCBF43926, CRC-16/MODBUS = 0x4B37, CRC-8/SMBUS = 0xF4

01 03 00 00 00 0A

CRC-16/MODBUS = 0xCDC5

DEADBEEF

MODBUS = 0xC19B, CCITT-FALSE = 0x4097, XMODEM = 0xC457, KERMIT = 0x1915

123456789 with expected value 0x29B1

CRC-16/IBM-3740 (your manual may call it CRC-16/CCITT-FALSE)

How to use the CRC calculator

1. 1

   Choose text or hex

   Protocol frames are almost always hex. Use text only when you are checksumming a literal string, such as the 123456789 self-test value.

2. 2

   Paste your data

   In hex mode separators are ignored, so 01 03 00 00 00 0A, 0x01 0x03 and 010300 00000A are all accepted.

3. 3

   Read the variant you need

   The table is grouped by width. Formal names come from the RevEng catalogue, with the aliases your device manual is likely to use printed underneath.

4. 4

   Or work backwards

   If you already have a checksum and want its variant, type it into the expected-value box and read the highlighted row.

Why your checksum does not match

Text mode, input "01 03" -> 5 bytes: 30 31 20 30 33

Hex mode, input "01 03" -> 2 bytes: 01 03

expected 0xC5CD  (bytes read in transmission order)

expected 0xCDC5  (bytes reassembled low-byte-first)

01 03 00 00 00 0A C5 CD    <- trailer included

01 03 00 00 00 0A          <- payload only

spec says: "trailer is a CRC-16"

spec says: "CRC-16/MODBUS, poly 0x8005, init 0xFFFF, refin/refout true"

When you need this

Debugging a Modbus link

A PLC rejects your frames and you need to know whether the CRC is wrong or merely byte-swapped. Compute CRC-16/MODBUS and compare both orderings.

Identifying an undocumented protocol

You captured traffic with a two-byte trailer that looks like a checksum. Feed the payload and the trailer to the reverse lookup and see which variant claims it.

Porting firmware between toolchains

A vendor library and your own implementation disagree. Comparing both against the catalogue check value shows which one drifted.

Writing or reviewing a specification

Naming "CRC-16" in a protocol document guarantees interoperability bugs. The parameter table gives you the six values that actually pin the algorithm down.

Verifying stored data

Filesystems, archive formats and flash images carry CRC-32 fields. Recomputing one tells you whether a block survived intact.

How CRC works

Polynomial representation

The table prints polynomials in normal (MSB-first) form: 0x8005 means x^16 + x^15 + x^2 + 1. Reflected implementations often show the same polynomial as 0xA001, and Koopman notation shifts it differently again. Three notations for one polynomial is a common source of failed ports.

The initial value

Starting the register at 0xFFFF rather than 0x0000 makes the checksum sensitive to leading zero bytes. With a zero init, prefixing a message with zeros leaves the CRC unchanged — which is exactly the corruption a framed protocol needs to catch.

Reflection

refin reverses bits within each input byte, refout reverses the final register. Hardware clocks bits MSB-first while byte-oriented software finds LSB-first cheaper, and the reflected parameter forms reconcile the two.

Final XOR

xorout is applied last, and it is not simply init at the other end. Zero bytes appended to the message are caught either way. What a non-zero xorout changes is the residue a receiver gets when it runs the CRC over message and checksum together: with xorout zero that residue is itself zero, so zeros appended after the CRC field still pass. It also makes the all-zero message produce a non-zero checksum.

The check value

Every catalogued variant publishes its result for the ASCII string 123456789. The 63 values shown on this page when that input is loaded are exactly those published constants, which is how the engine on this page is tested.

Getting a matching result

Name the parameters, not the algorithm

Write "poly 0x1021, init 0xFFFF, refin false, refout false, xorout 0x0000" in specifications. "CRC-16/CCITT" has meant at least three different things.

Check the byte order separately

When a checksum is one byte-swap away from matching, the algorithm is right and the framing is wrong. Treat those as two different bugs.

Validate against the check value first

Before debugging your data, confirm your implementation returns the catalogue value for 123456789. It separates a broken algorithm from a broken input in seconds.

Be explicit about what is covered

Most mismatches come from including or excluding start markers, addresses or length fields. Decide exactly which bytes the CRC spans and write it down.

Do not use CRC where a MAC is needed

CRC is linear and trivially forgeable. If an adversary could modify the data, use HMAC instead.

Frequently asked questions