HesapHanem

CRC-16/CCITT Checksum Calculator

Enter hexadecimal data to compute its CRC-16/CCITT checksum.

How it is calculated

The input is read as hexadecimal bytes, two digits per byte, with spaces ignored. The register starts at 0xFFFF. For each byte, the byte is XORed into the top 8 bits of the register, then the register is shifted left one bit eight times. Whenever the bit shifted out is 1, the register is XORed with the polynomial 0x1021. After the last byte the register is the CRC, printed as 0x followed by four uppercase hex digits. There is no final XOR and no bit reversal, which is what the CCITT-FALSE variant means. Input with an odd number of digits, a 0x prefix or non-hex characters returns no result.

Worked example

The text 123456789 is the ASCII bytes 31 32 33 34 35 36 37 38 39, so enter 313233343536373839. The register starts at FFFF. Each of the nine bytes is XORed into the high byte and passed through the eight shift steps with 0x1021, updating the register every time. After the ninth byte the register holds 0x29B1. This is the widely used test string for this variant, so a result of 0x29B1 confirms your implementation matches. The single byte 00 gives 0xE1F0 instead, because the start value is not zero.

Try this example →

Common mistakes

  • Typing the text itself instead of its hex bytes. The tool does not convert letters, so 123456789 must be entered as 313233343536373839, not as the digits.
  • Adding a 0x prefix. Unlike some converters, this tool rejects 0x and returns nothing, so leave it off.
  • Entering an odd number of hex digits. Every byte needs two digits, so 313 is rejected; write 0313 if the leading zero is meant.
  • Comparing against a different CRC-16 variant. XMODEM, Modbus and others use other starting values, polynomials or bit orders, so the same data gives different results.
  • Including the CRC bytes of the frame in the input and expecting the same answer. The CRC should be computed over the payload only, unless the protocol says otherwise.

About this calculator

CRC-16/CCITT-FALSE runs a message through polynomial division using the generator polynomial 0x1021 (x¹⁶+x¹²+x⁵+1) with a non-zero initial register value of 0xFFFF, producing a 16-bit remainder that acts as a checksum. The non-zero init distinguishes it from the plainer CRC-16/CCITT (init 0x0000) and lets it catch leading-zero errors that a zero-init variant would miss.

This variant, also catalogued as CRC-16/IBM-3740 or CRC-16/AUTOSAR, is common in serial and embedded protocols; XMODEM's CRC, by contrast, starts from 0x0000, so check which initial value your protocol expects. That is why firmware and protocol engineers need a calculator that matches the specific polynomial and initial value rather than a generic “CRC-16.”

Was this helpful?

You can pick up to 3 reactions.

Comments (1)

  • Editorial team

    The tool prints the result as one 16-bit value, but what goes on the wire is up to your protocol. For 0x29B1 some protocols send the bytes 29 B1 and others send B1 29, so confirm the byte order in your specification before comparing against a capture. If your device disagrees with the output here, first check that the CRC variant, not your data, is the difference. Which protocol or CRC variant do you work with most?

Popular calculators

Loan Calculator

Monthly payment, total interest and full amortization schedule.

Percentage Calculator

Percent change, percent of, and ratio calculations.

Discount Calculator

Calculate final price, savings, and discount amount.

BMI Calculator

Body mass index from height and weight (metric or imperial).

Age Calculator

Compute your exact age in years, months and days from a birth date.

Compound Interest Calculator

Calculate the final amount and interest earned with compounding.

All Calculators