CRC-8 Calculator — All Common Variants

Calculate the 8-bit cyclic redundancy check of any text or hex input across the eight most common CRC-8 variants at once, including the Maxim/1-Wire and SMBus polynomials. Each variant's polynomial, initial value, and reflection settings are applied for you, and results are shown in hex and decimal. It computes live and entirely in your browser.

How to use the CRC-8 Calculator — All Common Variants

Type or paste into the input and choose whether it is Text or Hex bytes. In hex mode you can separate bytes with spaces or commas and use an optional 0x prefix; in text mode the characters are converted to UTF-8 bytes first. The table updates live and shows, for each variant, the resulting CRC in both hexadecimal and decimal.

Eight variants are computed side by side because there is no single "CRC-8" — each is defined by a different combination of polynomial, initial value, input and output bit reflection, and final XOR. The classic check string 123456789 is provided as a default so you can confirm the values against published check constants: SMBus yields 0xF4, Maxim/1-Wire 0xA1, DVB-S2 0xBC, and so on. Match the variant name to whatever device or protocol you are working with — for example, Dallas/Maxim 1-Wire sensors use the Maxim row.

The calculation runs entirely in your browser, so it is instant, works offline, and nothing you enter is uploaded anywhere.

What a CRC-8 is and why there are so many

A cyclic redundancy check is an error-detecting code that treats your data as the coefficients of a big binary polynomial and divides it by a fixed shorter polynomial; the remainder of that division is the CRC. The point is sensitivity to corruption: flip a single bit anywhere in the message and the remainder changes, so a receiver that recomputes the CRC and compares it against the transmitted one can detect the damage. The 8-bit family produces a one-byte result, which is small and cheap to compute, making it the standard choice for short messages where a full 16- or 32-bit checksum would be overkill — think a temperature reading from a sensor, a packet on an embedded bus, or a smart-card command.

The reason there is no single CRC-8 is that the algorithm has several free parameters, and different standards bodies picked different values. The most important is the polynomial, the divisor: SMBus uses 0x07, the Dallas/Maxim 1-Wire bus uses 0x31, DVB-S2 uses 0xD5, and so on, each chosen for good error-detection properties in its target environment. Beyond the polynomial, a variant specifies an initial value loaded into the register before processing (often 0x00 or 0xFF), whether the input bytes and the output are bit-reflected (least-significant-bit-first, which matches how some hardware shifts bits), and a final XOR applied to the result. Two variants can share a polynomial yet produce completely different values because one reflects the bits and the other does not, which is exactly why mixing them up leads to checksums that never match.

A useful way to pin down which combination an implementation uses is the check value: the CRC of the nine ASCII bytes 123456789. Catalogs of CRC parameters publish this constant for every named variant, so computing it is an instant fingerprint — if your code produces 0xF4 for that string you are running the SMBus parameters, and 0xA1 with reflection means Maxim. Because the bitwise computation is short and the parameters are the only thing that varies, showing all the common variants together lets you find the one that matches your device without trial and error. The math is identical to larger CRCs; only the register width and the constants change, so understanding the 8-bit case is a clean way to understand CRCs in general.

Common use cases

  • 1-Wire / Maxim devices. Verify the CRC byte on Dallas/Maxim sensor ROM codes and scratchpads.
  • Embedded protocols. Compute the SMBus, I.432.1, or CDMA2000 CRC for a packet by hand.
  • Identifying a variant. Match an unknown CRC-8 against the check value to find its parameters.
  • Firmware debugging. Confirm your device firmware\'s CRC matches a reference implementation.

Frequently asked questions

Which CRC-8 variant should I use?
Use whichever your device or protocol specifies. Dallas/Maxim 1-Wire parts use the Maxim row (polynomial 0x31, reflected); SMBus uses 0x07. The table shows all common variants so you can pick the matching one.

Why do variants with the same polynomial differ?
Because the initial value, bit reflection, and final XOR also vary. Two variants can share polynomial 0x07 yet produce different results if one reflects the input and output bits and the other does not.

What is the check value 123456789?
It is the standard test string. Computing the CRC of the ASCII bytes 1-9 gives a published constant for each variant (for example 0xF4 for SMBus), which confirms an implementation uses those exact parameters.

Can I input raw bytes instead of text?
Yes. Switch the input type to Hex bytes and enter values separated by spaces or commas, with an optional 0x prefix. The CRC is then computed over those exact bytes.