FirmGod

Modbus CRC16 Calculator

Calculate the Modbus RTU CRC-16 for any frame. Paste hex, get the checksum in both byte orders, and see the complete frame ready to send.

Spaces, commas, dashes, and 0x prefixes are all accepted.

Examples:
CRC-16/MODBUS0xCDC5
Decimal52677
Low byte (sent first)0xC5
High byte (sent second)0xCD
CRC on the wireC5 CD
Complete frame01 03 00 00 00 0A C5 CD
Payload length6 bytes

How the Modbus CRC works

Modbus RTU protects every frame with a 16-bit cyclic redundancy check. The transmitter computes it over the whole frame and appends two bytes; the receiver recomputes it and silently discards the frame on any mismatch. There is no negative acknowledgement for a bad CRC — the request simply times out, which is why a checksum bug usually presents as an unresponsive device rather than an error message.

ParameterValue
Width16 bits
Polynomial0x8005 (0xA001 in reflected form)
Initial value0xFFFF
Input reflectedYes
Output reflectedYes
Final XOR0x0000
Check value for "123456789"0x4B37

The byte order trap

Modbus RTU is big endian everywhere — addresses, quantities, register values — except for the CRC, which is transmitted low byte first. A frame ending in a CRC of 0xCDC5 therefore ends with the bytes C5 CD. Implementations that append the CRC in the same order as every other field produce frames that are byte-perfect apart from the last two, and the device ignores them without complaint.

The tool above shows both bytes separately and the complete frame, so the ordering is explicit rather than something you have to remember.

A worked example

A request to read ten holding registers starting at address 0 from slave 1 has the payload01 03 00 00 00 0A. Its CRC-16/MODBUS is 0xCDC5, so the frame transmitted on the bus is:

01 03 00 00 00 0A C5 CD

Reading the fields back: slave address 01, function code 03 (read holding registers), starting address 0000, quantity 000A (ten registers), then the CRC low byte and high byte.

Implementing it in firmware

Two approaches are common. The bitwise version processes each bit and needs no storage, which suits very small microcontrollers. The table-driven version precomputes 256 entries and processes a byte at a time, trading 512 bytes of flash for roughly an eight-fold speedup. On anything with room for the table, use it — CRC calculation on long frames is otherwise a measurable part of the response time at high baud rates.

Whichever you write, verify it against the check value: the CRC of the ASCII string 123456789must be 0x4B37. That single test catches almost every parameter mistake, including a reflected polynomial applied in the wrong direction.

Frequently asked questions

Which byte goes on the wire first?

The low byte. Modbus RTU transmits every 16-bit field most significant byte first except the CRC, which is sent low byte first. A CRC of 0xCDC5 appears on the wire as C5 CD. This single exception is the most common reason a hand-built frame is rejected.

Which bytes are included in the CRC?

Everything from the slave address through the last data byte — the entire frame except the two CRC bytes themselves. The silent intervals that delimit RTU frames are not part of the calculation.

What are the CRC-16/MODBUS parameters?

Polynomial 0x8005 (0xA001 reflected), initial value 0xFFFF, input reflected, output reflected, and no final XOR. It is the same algorithm as CRC-16/ARC apart from the initial value.

Does Modbus TCP use this CRC?

No. Modbus TCP relies on the TCP checksum and replaces the CRC with a 7-byte MBAP header. Only RTU frames carry a CRC-16. Modbus ASCII uses an LRC checksum instead.