CRC Calculator: Modbus CRC-16, CRC-32 and CRC-8 Online

How it works

A CRC (cyclic redundancy check) is a short check value appended to a block of data so the receiver can tell whether it was corrupted on the way. Anyone talking to a device over Modbus RTU, writing a serial protocol or comparing a file's CRC-32 with a published value has to compute it. Type the bytes in the left panel as hex: for "01 03 00 00 00 0A" (read 10 registers starting at address 0 from device 1) the CRC-16/MODBUS result is 0xCDC5, and it goes on the wire low byte first as "C5 CD"; the tool prints the full frame "01 03 00 00 00 0A C5 CD". Bytes may be separated by spaces, commas, colons or a 0x prefix. If you type text, it is converted to UTF-8 bytes; "123456789" is the standard test input of every CRC and gives CBF43926 for CRC-32. If you do not know the algorithm, read the default "All" table and type the value you already have into "Expected CRC".

This tool is also known as crc calculator, crc16 modbus calculator, crc32 calculator, crc16 ccitt calculator, crc calculator online, crc8 calculator, modbus crc calculator.

What is CRC (cyclic redundancy check)?

A CRC treats the data as a long binary number, divides it by a fixed binary polynomial and keeps the remainder as a check value. The sender appends the remainder, the receiver repeats the division and compares; flipping even one bit changes the remainder. CRCs protect serial links (Modbus, CAN), network frames (Ethernet) and archive formats (ZIP, PNG). They come in 8, 16, 32 and 64-bit widths; the wider the CRC, the lower the chance that an error slips through.

What is Polynomial and CRC parameters?

Six values define a CRC algorithm completely: width (number of bits), poly (the divisor), init (starting register value), refin (whether each input byte is processed low bit first), refout (whether the result is bit-reversed) and xorout (a value XORed into the result). Ross Williams described this model, and Greg Cook's CRC catalogue lists hundreds of algorithms in exactly this form. If your datasheet gives these six values, enter them as they are with "Custom algorithm".

What is the difference between a CRC and a checksum?

A simple checksum adds or XORs the bytes, so two swapped bytes or two errors that cancel each other leave it unchanged. A CRC is a polynomial division in which the position of every bit counts: it always catches a single-bit error and any burst of errors no longer than its width, and it detects swapped bytes with very high probability. That is why Modbus, Ethernet and ZIP use a CRC instead of a plain sum, while formats such as NMEA (GPS sentences) and Intel HEX still rely on a simple checksum, which this tool does not compute.

Different CRCs with the same name: CCITT, Modbus and the byte order trap

"CRC-16" is not one calculation. CRC-16/CCITT-FALSE, XMODEM, KERMIT and X-25 all use polynomial 0x1021, yet for "123456789" they return 29B1, 31C3, 2189 and 906E. The difference comes from the initial value (FFFF or 0000), from which end of each byte is processed first (reflection) and from the final XOR. Modbus uses polynomial 0x8005 with initial value FFFF and reflected bits. If a datasheet only says "CRC-16", check the "All" table instead of trusting one variant.

The second trap is byte order. Modbus RTU sends the low byte of the CRC first: the computed value is 0xCDC5, but the bytes on the line are "C5 CD". If you copy the two bytes from a capture and search for "C5CD", nothing matches. That is why every result shows both byte orders and the expected value is also tried with swapped bytes, flagged as "byte order swapped". With text input, line endings matter too: Windows ends a line with two bytes (0D 0A), Linux with one (0A), and a single extra byte changes the CRC completely.

Which algorithm should you choose?

The protocol or file format decides the algorithm, so match it rather than guess. If the documentation gives a parameter table (polynomial, initial value, reflection, final XOR), enter those values exactly with "Custom algorithm".

• Modbus RTU (PLCs, energy meters, drives): CRC-16/MODBUS
• XMODEM/YMODEM transfers and many embedded bootloaders: CRC-16/XMODEM
• Datasheet says "CRC-16-CCITT, initial value 0xFFFF": CRC-16/CCITT-FALSE (IBM-3740)
• ZIP, PNG, gzip and Ethernet: CRC-32 (ISO-HDLC)
• ext4, Btrfs, iSCSI and the SSE4.2 instruction: CRC-32C
• Dallas/Maxim 1-Wire sensors (DS18B20): CRC-8/MAXIM
• XZ archives: CRC-64/XZ

Frequently asked questions

How do you calculate a Modbus CRC?

Modbus RTU uses CRC-16/MODBUS: polynomial 0x8005 (0xA001 reflected), initial value 0xFFFF, reflected bits, no final XOR. Enter the address, function code and data bytes as hex; the result is appended to the frame low byte first. For "01 03 00 00 00 0A" the CRC is 0xCDC5 and the transmitted frame is "01 03 00 00 00 0A C5 CD".

What is the difference between CRC-16 CCITT and XMODEM?

Both use polynomial 0x1021; CRC-16/CCITT-FALSE starts from 0xFFFF and XMODEM from 0x0000, so the same data gives different results: 29B1 versus 31C3 for "123456789". Choose by the initial value in your documentation, or compare both results against a known packet.

How can I find out which algorithm produced my CRC?

Take a known packet (data plus CRC), put the data bytes in the left panel and the CRC in "Expected CRC", and leave the algorithm on "All". The row that produces the value is marked as a match, and a value written with swapped bytes is reported separately. If nothing matches, make sure the CRC bytes themselves are not part of the input and the data is byte-for-byte identical.

Is CRC-32 the same as MD5 or SHA-256?

No. CRC-32 is a fast check value designed to catch accidental corruption during transfer or storage; it gives no protection against deliberate changes, because different data with the same CRC is easy to construct. To prove a file was not tampered with, use a cryptographic hash such as SHA-256.