CRC-16 Checksum Calculator

Features

• Nine common variants: ARC, Modbus, USB, MAXIM, CCITT-FALSE, XMODEM, KERMIT, X-25 and DNP
• Each variant says where it is used — Modbus frames, 1-Wire devices and X.25 frames each need a specific one
• Output as hexadecimal (upper or lower case) or decimal
• Non-ASCII text hashed as UTF-8 bytes, matching other implementations
• Every variant is anchored to the catalogue check value, so parameters cannot be mistyped
• Computed locally; your content never leaves the browser

How to use

1. Paste your content; the result appears as you type
2. Pick the variant the other system uses (choose CRC-16/MODBUS for Modbus)
3. Switch between hex and decimal, or uppercase, as needed
4. Click Copy to take the checksum

FAQ

Why are there so many CRC-16 variants?

Because the 16 in CRC-16 only says the checksum is 16 bits wide and nothing else. Which polynomial, what initial value, whether input bytes are reflected, and whether the result is XORed with a constant — those four parameters were decided independently by different vendors over the years, producing dozens of incompatible implementations under one name. ARC (also called IBM) came first; Modbus, USB and X-25 are variants of it for their own contexts. Names do not tell you which is which, which is why every entry here is labelled with its use.

Which one does Modbus use?

CRC-16/MODBUS: polynomial 0x8005, initial value 0xFFFF, both input and output reflected, no final XOR. It occupies the last two bytes of a Modbus RTU frame, low byte first. Note that Modbus TCP does not use it (the Ethernet layer below handles integrity); only RTU and ASCII modes need it computed by hand.

How do I find out which variant the other system uses?

Three ways, in order of reliability. First, the protocol documentation, which usually states the polynomial and initial value. Second, find a known verification value — the standard check input is the string 123456789, and every variant here matches the value registered in the CRC catalogue, so you can try them until one lines up. Third, read the source: the reflected form of 0x8005, which is 0xA001, appearing in code almost always means the ARC family.

Why does my result not match the value in the manual?

Two causes account for nearly all cases. Either the variant is wrong — from the same 0x8005 polynomial, ARC gives BB3D, Modbus gives 4B37 and MAXIM gives 44C2 — or the byte range is wrong. CRC operates on a byte stream, so if you paste only the payload while the other side computes over the whole frame (address, function code and data), the results cannot agree. Confirm that both sides cover exactly the same bytes.