Protocol calculator

Modbus CRC Calculator

CRC-16/Modbus value, low-byte first frame append, and RTU test vectors.

CRC-16/Modbus calculator

Enter ASCII text or hex bytes. The RTU frame output appends CRC low byte first, then high byte.

Message bytes Hex mode accepts spaces, commas, and 0x prefixes. Example: 01 03 00 00 00 0A.

Input format

Example frame

CRC: 0x4B37
Low byte: 0x37
High byte: 0x4B
Frame with CRC: 31 32 33 34 35 36 37 38 39 37 4B

Known check: ASCII 123456789 produces CRC-16/Modbus 0x4B37.

Formula notes

CRC-16/Modbus starts at 0xFFFF, processes each byte least-significant bit first, and uses the reversed polynomial 0xA001. Modbus RTU appends the low CRC byte before the high CRC byte.

What this calculator is for

Use this Modbus CRC calculator to verify RTU request frames, response frames, serial analyzer captures, and embedded firmware implementations. Enter ASCII text for known check vectors, or switch to hex mode when copying raw bytes from an RS-485 trace.

The calculator runs in the browser and reports both the numeric CRC and the exact RTU frame bytes to append. That distinction matters because Modbus documentation often names the 16-bit value, while serial traces show low byte then high byte on the wire.

CRC-16/Modbus parameters

Initial value	`0xFFFF`
Polynomial	`0x8005` normal form, `0xA001` reversed form
Input processing	Least-significant bit first
Final XOR	None
RTU byte order	Low CRC byte first, then high CRC byte

Worked RTU example

A common request frame such as 01 03 00 00 00 0A asks slave address 01 to read holding registers with function 03. Enter those six bytes without any checksum bytes. The calculator appends the two CRC bytes in RTU order, so you can compare the final frame against a serial analyzer capture.

Common checks

Use hex mode when copying bytes from a serial analyzer.
Do not include the existing CRC bytes when recalculating a request.
If another tool shows 0x374B, check whether it is displaying transmission byte order instead of the numeric CRC.

RTU, TCP, and ASCII mode differences

Modbus RTU uses CRC-16 because it runs over serial links. Modbus TCP does not include this CRC field because TCP/IP and Ethernet already provide lower-layer integrity checks. Modbus ASCII uses an LRC checksum rather than CRC-16, so an ASCII-mode Modbus frame will not match an RTU CRC calculation.

Debugging CRC mismatches

Check that the slave address and function code are included in the calculation.
Remove timestamps, direction markers, start bits, stop bits, and whitespace copied from analyzer software.
Verify that the device is really using Modbus RTU and not a vendor-specific CRC variant.
Compare against the known check vector: ASCII 123456789 produces 0x4B37.

Using the result in firmware tests

Keep at least one fixed request frame and one known response frame in your unit tests. That makes it easier to catch byte-order regressions when a CRC function is optimized, ported from C to another language, or changed from bitwise calculation to a lookup-table implementation. The numeric CRC and the transmitted low/high byte pair should both be asserted so display-order mistakes do not slip through.

For field debugging, save the raw request bytes before the CRC, the calculated CRC, and the full frame with CRC appended. That evidence is easier to compare with a logic analyzer trace than a screenshot of a terminal window. It also makes vendor support conversations much faster.

Before using the frame

Confirm the device is using Modbus RTU CRC-16, not Modbus ASCII LRC.
Append the low CRC byte first on the wire.
Keep a known vector such as ASCII 123456789 equals 0x4B37 in your test notes.

Frequently asked questions

How do I calculate a Modbus RTU CRC?

Start with 0xFFFF, XOR each data byte into the low byte of the CRC register, process 8 bits least-significant bit first with the reversed polynomial 0xA001, then append the low CRC byte before the high CRC byte.

What polynomial does Modbus CRC use?

CRC-16/Modbus uses the CRC-16 polynomial 0x8005, processed in reversed bit order as 0xA001. The initial value is 0xFFFF, input bytes are reflected, and there is no final XOR.

Why does another calculator show the CRC bytes reversed?

Some tools show the numeric CRC value, while others show the transmission byte order. Modbus RTU transmits the low byte first, so a numeric CRC of 0x4B37 is appended to the frame as 37 4B.

Do I include existing CRC bytes when recalculating a frame?

No. Enter only the address, function code, and data bytes before the checksum. If you include the two existing CRC bytes, you are calculating a new CRC over a frame that already contains a checksum.

Does Modbus TCP use the same CRC?

No. Modbus TCP does not append the RTU CRC field. It uses the MBAP header and relies on TCP/IP and Ethernet integrity checks. CRC-16/Modbus is for Modbus RTU serial frames, not TCP packets.