Hex CRC16 Calculator
Compute the CRC-16/MODBUS checksum from hex byte input — the CRC16 variant used in the Modbus industrial protocol.

Built by
Swapnil SanghviFull-Stack Web Developer & WordPress Developer
Swapnil Sanghvi is a full-stack web and WordPress developer, UI designer, and full-time freelancer who builds and maintains Hex Calculator.
Further reading: Cyclic redundancy check — Wikipedia
How CRC-16/MODBUS Is Computed
Like CRC32, CRC-16/MODBUS processes the input one byte at a time using a table derived from its generator polynomial (0xA001, the bit-reflected form of 0x8005), starting from an initial value of 0xFFFF. Unlike CRC32, there's no final inversion step.
CRC16 Test Vector, Verified
CRC-16/MODBUS("123456789") = 0x4B37
CRC16(0x313233343536373839) = 0x4B37
Input bytes: "123456789" (9 ASCII bytes) Run CRC-16/MODBUS over all 9 bytes Result: 0x4B37 (the official check value)
| Step | Description | Result |
|---|---|---|
| Encode input as bytes | "123456789" -> 0x313233343536373839 (9 bytes) | 9 bytes |
| Run CRC-16/MODBUS | process each byte through the table-driven update, starting at 0xFFFF | running 16-bit value |
0x4B37 is the standard published check value for CRC-16/MODBUS — a correct implementation reproduces this exact result for this exact input.
Where CRC16 Actually Comes Up
Verifying a Modbus RTU Message
Modbus RTU devices append a CRC16 to every message frame — recomputing it over the received bytes and comparing to the trailing value is how a Modbus device or master detects a corrupted transmission.
message bytes + CRC16 trailer
Debugging a Serial Protocol Implementation
When a device rejects a Modbus command, checking whether your computed CRC16 matches what the device expects is often the first thing to verify.
computed CRC16 == device's expected CRC16
Sanity-Checking a Custom CRC16 Implementation
Running the standard "123456789" test vector through your own CRC16 code and comparing against 0x4B37 catches a wrong polynomial or initial value before it reaches production.
CRC16("123456789") == 0x4B37
Why Use This Calculator Instead of Doing It by Hand
- Verified against the official CRC-16/MODBUS check value before shipping
- Table-driven implementation computes instantly even on longer byte sequences
- Runs entirely in your browser — nothing you type gets sent anywhere
- Accepts hex byte input directly, matching how Modbus frames are usually represented
Limitations
- Computes only the CRC-16/MODBUS variant — other CRC16 flavors (CRC-16/CCITT, CRC-16/XMODEM) use different polynomials and initial values and will not match.
- Input is treated as raw hex bytes — an odd number of hex digits gets a leading zero nibble added first.
Frequently Asked Questions
Which CRC16 variant does this calculator use?
CRC-16/MODBUS (polynomial 0xA001, initial value 0xFFFF) — the specific variant used by the Modbus industrial communication protocol. Like CRC32, "CRC16" alone is ambiguous since other CRC16 variants (like CRC-16/CCITT) use different parameters and produce different results.
How do I verify this calculator computes CRC16 correctly?
Enter 313233343536373839 (the hex bytes for the ASCII string "123456789") — the standard check value for CRC-16/MODBUS on that input is 0x4B37, which this calculator reproduces exactly.
Where is CRC-16/MODBUS actually used?
Every Modbus RTU message ends with a 2-byte CRC16 field, which the receiving device recomputes and compares to detect a corrupted transmission on the serial line.
Is CRC16 stronger than CRC8, or weaker than CRC32?
Generally yes to both — a wider CRC has a larger set of possible check values, which reduces (but never eliminates) the chance that two different corrupted messages produce the same check value by coincidence.