⌁ Embedded & Hardware

CRC Calculator (CRC-8, CRC-16, CRC-32, Modbus)

Calculate CRC-8, CRC-16 (Modbus, CCITT, XMODEM), CRC-32 and custom CRCs over text, hex bytes or files, with wire byte order and generated C code.

14 catalogue presets Custom 1–64 bit C code (tested with gcc) Files in a worker

Loading CRC Calculator…

What this page sends

Your input: Text, hex and files are processed in this tab; files are read in chunks by a Web Worker and not sent to a server.
Page load: Loading the page requests HTML, scripts and images from ByteKiln, fonts from Google Fonts, and sends Google Analytics page views, tool-usage events and catalog interactions (tool/category IDs, result status and whether a click followed search — never your input, output or search terms). Privacy & sharing

How the CRC Calculator (CRC-8, CRC-16, CRC-32, Modbus) Works

A CRC is a few lines of code, but getting one to match a device, a datasheet or another program is notoriously fiddly. Two implementations can both call themselves "CRC-16" and produce different values for the same bytes, because a CRC is defined by six parameters — width, polynomial, initial value, whether input bytes and the output are bit-reflected, and a final XOR — and small differences in any of them change the result completely. On top of that, the value you calculate and the bytes you transmit can be in different orders. This calculator implements the parameter model used by the CRC RevEng catalogue, includes the presets embedded developers actually meet (Modbus, CCITT-FALSE, XMODEM, KERMIT, SMBus, Dallas 1-Wire, CRC-32 and CRC-32C among them), and lets you define any custom CRC from 1 to 64 bits. It shows every preset's result side by side so you can identify an unknown CRC from a known-good value, displays the conventional wire byte order, and writes a C implementation you can drop into firmware.

Engines

Widths from 8 to 32 bits use a 256-entry lookup table and 32-bit integer arithmetic, fast enough for large files. Any other width, up to 64 bits, uses a straightforward bit-by-bit implementation with BigInt. Both are checked against the catalogue check values for "123456789".

Input

Text is encoded as UTF-8 and the exact bytes are shown when the text isn't plain ASCII. Hex input accepts spaces, commas, 0x and \x prefixes and braces. Files are processed in 4 MB chunks by a Web Worker, with a progress bar, so the page never freezes.

Byte order

CRC algorithms with reflected output (Modbus, CRC-32, KERMIT) are conventionally transmitted least-significant byte first; non-reflected ones most-significant byte first. The calculator shows big- and little-endian bytes and appends the CRC to your hex frame in wire order.

Checksums and code

Sum-8, XOR-8 (LRC), Fletcher-16 and Adler-32 are calculated alongside. The C generator writes a bitwise version (smallest code) and a table-driven version (fastest), plus an Arduino sketch that prints the check value and appends the CRC to a frame.

Working with the CRC Calculator

Check it against a known Modbus frame

The Modbus RTU specification's own example is a read of three holding registers starting at 0x006B from slave 0x11: the six bytes 11 03 00 6B 00 03. Enter them as hex with the CRC-16/MODBUS preset and the result is 0x8776. Modbus sends the CRC low byte first, so the full frame on the wire ends 76 87 — exactly the frame printed in the spec.

The Load example button uses another common request, 01 03 00 00 00 0A (slave 1, ten registers from 0), whose CRC is 0xCDC5, sent as C5 CD. A good sanity check for your own code: run the CRC over the whole frame including its two CRC bytes and a correct Modbus frame always gives 0x0000.

Modbus RTU frames and CRC-16/MODBUS

11 03 00 6B 00 03        → CRC 0x8776 → frame: 11 03 00 6B 00 03 76 87
01 03 00 00 00 0A        → CRC 0xCDC5 → frame: 01 03 00 00 00 0A C5 CD
01 03 00 00 00 0A C5 CD  → CRC 0x0000 (a valid frame checks to zero)

Which CRC-16 is my device using?

Datasheets often just say "CRC-16". If you have one real frame and its CRC, enter the frame and compare the result across the CRC-16 presets: Modbus (init 0xFFFF, reflected), XMODEM (init 0, not reflected), CCITT-FALSE/IBM-3740 (init 0xFFFF, not reflected) and KERMIT (init 0, reflected) are the usual suspects. If the right value appears byte-swapped, the parameters are right and only the transmission order differs.

Limitations

It computes CRCs you describe: the preset catalogue plus custom width, polynomial, init, reflection and xorout. Finding unknown parameters from sample frames is limited to matching the presets, not a full parameter search.
Widths above 32 bits (up to 64) use a slower bit-by-bit engine; very large files at those widths take a while.
Hex input must be whole bytes; bit-level frames that aren't a multiple of eight bits can't be entered.
The generated C is portable C99; it isn't tuned for hardware CRC peripherals such as the STM32 CRC unit.

FAQ

Short answers for the things developers usually ask before trusting a tool.

Is my data uploaded?

No. CRCs are computed in your browser; files are read in chunks by a background worker on your machine and are not sent to a server.

Which CRC-16 do I need?

It depends on the protocol, and the names are confusing. Modbus RTU uses CRC-16/MODBUS. "CRC-16/CCITT" in most embedded code is actually CRC-16/IBM-3740 (also called CCITT-FALSE, init 0xFFFF), while XMODEM uses init 0x0000 and KERMIT is the reflected variant. If you have a known-good frame and its CRC, enter the expected value and the calculator lists every preset that matches.

Why is the Modbus CRC shown as C5 CD when the value is 0xCDC5?

Modbus RTU transmits the CRC low byte first. The CRC value is 0xCDC5, so the bytes on the wire are C5 CD. The calculator shows the value and the wire order separately, and the "frame + CRC" line appends the bytes in wire order.

What do refin, refout and xorout mean?

They are the parameters of the Rocksoft/RevEng CRC model. refin reflects each input byte (processes bits LSB first), refout reflects the final register, init is the register's starting value and xorout is XORed into the result. Together with width and polynomial they fully define a CRC.

Is the generated C code correct?

The test suite generates the bitwise and table-driven C functions for every preset, compiles them with gcc -Wall -Werror and checks each one against the standard "123456789" check value.

How do I enter hex bytes?

Any common notation works: 01 03 00, 0x01,0x03,0x00, 010300, \x01\x03 or {0x01, 0x03}. An odd number of hex digits is reported as an error instead of being silently padded.

Related tools

Useful follow-ups when one conversion usually turns into three more.

security-cryptography

Read the CRC Calculator guide