CRC-16 Calculator

Compute CRC-16 checksums across standard variants — CCITT, Modbus, XMODEM, USB, MAXIM & Custom Poly.

Input Mode

Sample Presets

Input String

Input Size11 Bytes

Bit Length88 Bits

Standard Variants8 Preset Algorithms

Export Action

Computed Checksums

Algorithm Variant	Hex Checksum	Decimal	Binary (16-bit)	Common Usage
CRC-16/CCITT-ZERO	0x992A	39210	1001100100101010	Alias of XMODEM (identical parameters) — Bluetooth, SD cards, serial links
CRC-16/CCITT-FALSE	0x4D25	19749	0100110100100101	Non-reflected, init 0xFFFF — the model most libraries label plainly "CCITT"
CRC-16/MODBUS	0xDAED	56045	1101101011101101	Used in Modbus RTU industrial automation
CRC-16/XMODEM	0x992A	39210	1001100100101010	XMODEM file transfer — the catalogue name for these parameters (see CCITT-ZERO)
CRC-16/ARC	0x3EEB	16107	0011111011101011	Standard CRC-16 (IBM / LHA / ARC archives)
CRC-16/KERMIT	0x23C9	9161	0010001111001001	Reversed CCITT variant used in Kermit file transfer
CRC-16/USB	0x2512	9490	0010010100010010	Used in USB token packets & hardware devices
CRC-16/MAXIM	0xC114	49428	1100000100010100	Used in Dallas/Maxim 1-Wire chips

CRC-16 algorithms and parameters explained

CRC-16 (Cyclic Redundancy Check) produces a 16-bit error-detecting checksum for data integrity verification in serial communications, file transfers, and industrial hardware protocols. Different standards configure different polynomial formulas (e.g. 0x1021 for CCITT, 0x8005 for Modbus/IBM), initial seed registers, input bit reflections, and output XOR masks. This online tool computes all major standard CRC-16 variants instantly in client-side JavaScript without transmitting any data over the network.

Built and maintained by Meet Shah · Last updated 2 August 2026

What this tool is used for

Computing a Modbus CRC for a serial frame you are debugging.
Checking a device's checksum against your own implementation.
Comparing CRC-16 variants to identify which one a protocol uses.
Verifying a frame captured from a serial bus against its trailing CRC.
Producing a checksum for a test fixture.

Frequently Asked Questions

Why are there so many CRC-16 variants?: Because CRC-16 names a family, not an algorithm. Each variant fixes a polynomial, an initial value, whether input and output bits are reflected, and a final XOR — change any one and the checksum differs completely for the same data.
What does the polynomial do?: Defines the division. CRC is polynomial long division over GF(2), and the polynomial determines which error patterns are guaranteed to be caught — CCITT's 0x1021 and IBM's 0x8005 were each chosen for their detection properties in a particular medium.
What errors does a CRC-16 catch?: All single-bit and double-bit errors, all odd numbers of bit errors, and every burst up to 16 bits. Beyond that it is probabilistic — roughly one in 65,536 random corruptions passes, which is why CRC-32 exists for larger payloads.
Is a CRC a security check?: No. It is linear, so an attacker can modify the data and recompute a matching checksum trivially. It detects accidental corruption and nothing more — integrity against a deliberate change requires an HMAC or a signature.
Why does my CRC not match another tool's?: Almost always a parameter mismatch rather than a bug. Reflected input and output are the usual culprits — CCITT-FALSE and XMODEM share a polynomial and differ in initial value, and the two are constantly confused in documentation.

Common errors and gotchas

Choosing the wrong variant, since CCITT, CCITT-FALSE, Modbus and XMODEM all give different results.
Getting the byte order wrong when appending the CRC, which several protocols specify explicitly.
Including the CRC bytes in the calculation, which the protocol usually excludes.
Assuming CRC-16 offers any protection against deliberate tampering, which it does not.
Computing over text when the protocol frames bytes, where the encoding changes the input.