Which CRC-16 does this calculator use?
This calculator computes CRC-16/ARC: polynomial 0x8005 applied bit-reversed, an initial register of zero, and no final XOR. It's the algorithm most often meant by a bare "CRC-16", and the one used by the old ARC and LHA archivers. Type 123456789 and you should see bb3d, the variant's published check value.
That check value matters because many 16-bit CRCs are in use, and they differ only in a handful of parameters. The CRC catalogue records each one with the result it gives for the ASCII string 123456789, and that single number is the fastest way to tell variants apart.
How the algorithm processes each byte
The tool's implementation is the classic bit-at-a-time version of CRC-16/ARC:
- Start with a 16-bit register set to
0x0000. - XOR the next input byte into the low 8 bits of the register.
- Repeat eight times: if the lowest bit is 1, shift the register right one bit and XOR it with
0xA001; otherwise just shift right. - Move to the next byte and go back to step 2.
- After the last byte, the register is the CRC. Print it as 4 lowercase hex digits, zero-padded.
0xA001 is 0x8005 with its bits mirrored, which is what lets the loop shift right and handle each byte least-significant bit first. Text is encoded as UTF-8 first, so non-ASCII characters contribute more than one byte; é is C3 A9 and gives 8e90.
Same input, six different CRC-16s
Every value below was computed for the 9-byte ASCII string 123456789 and agrees with the catalogue. Only the first row is what this tool outputs.
| Catalogue name | Poly | Init | Reflected | Final XOR | Check | Common home |
|---|---|---|---|---|---|---|
| CRC-16/ARC (this tool) | 0x8005 | 0x0000 | yes | 0x0000 | bb3d | ARC, LHA archives |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | yes | 0x0000 | 4b37 | Modbus RTU |
| CRC-16/USB | 0x8005 | 0xFFFF | yes | 0xFFFF | b4c8 | USB data packets |
| CRC-16/XMODEM | 0x1021 | 0x0000 | no | 0x0000 | 31c3 | XMODEM, ZMODEM |
| CRC-16/IBM-3740 | 0x1021 | 0xFFFF | no | 0x0000 | 29b1 | Often sold as "CCITT-FALSE" |
| CRC-16/KERMIT | 0x1021 | 0x0000 | yes | 0x0000 | 2189 | Kermit, Bluetooth; often called "CCITT" |
The naming is a mess. "CRC-16/CCITT" refers to the KERMIT variant in the catalogue, while many code samples labelled CCITT actually compute IBM-3740. Trust the check value over the name: run 123456789 through whatever you're matching and compare against the table.
Worked example and a sanity check
| Input | CRC-16/ARC |
|---|---|
123456789 |
bb3d |
hello world |
39c1 |
Hello world |
f96a |
The quick brown fox jumps over the lazy dog |
fcdf |
One capital letter changes all four digits. To double-check the first row in another tool, convert bb3d with a hex to decimal converter and you get 47933; some embedded toolchains print CRCs in decimal.
Working with protocol frames
The most common reason people reach for a CRC-16 tool is debugging a serial or fieldbus frame, and that's where a text box gets awkward. A Modbus request such as 01 03 00 00 00 0A is six raw bytes, but typed here it becomes 17 characters of text. Two practical routes:
- If the frame happens to be printable ASCII, convert it with text to hex to confirm the bytes you're feeding in are the bytes on the wire.
- If it's binary, compute the CRC in code. The five-step loop above is about ten lines in C, Python or JavaScript, and switching to Modbus means changing only the initial value to
0xFFFF.
Byte order is the other trap. A CRC of bb3d might appear on the wire as 3d bb when the protocol sends the low byte first, as Modbus RTU does.
Limits worth knowing
A 16-bit CRC has only 65,536 possible values. That's plenty for spotting a corrupted 50-byte packet, but with a few hundred random inputs you're likely to see two with the same CRC, so never use it as an identifier or for deduplication. It's also not security: like every CRC it can be recomputed by anyone who changes the data. For longer data or larger files, CRC-32 gives four billion values, and for tamper detection you need a keyed HMAC.
Last updated