CRC Checksum Calculator

About this tool

Compute a CRC checksum — 11 variants across CRC-8, CRC-16, CRC-24, CRC-32, and CRC-64 — over text or raw hex bytes, the same kind of error-detecting checksum used in serial protocols, firmware update files, and embedded communication frames.

Everything is computed locally in your browser — nothing is uploaded.

How CRC works, conceptually. A Cyclic Redundancy Check treats the input bytes as one long binary number and divides it by a fixed binary constant (the "polynomial") using a bitwise version of long division — the remainder of that division is the checksum. Because a single flipped bit changes the remainder in a predictable way, a receiver can run the same division on data it receives and compare remainders: if they don't match, at least one bit was corrupted in transit. It's fast to compute in hardware, which is why it's built into so many low-level protocols rather than something slower like a cryptographic hash.

Why so many variants exist. "CRC-16" and "CRC-32" name a checksum width, not one fixed algorithm — the polynomial, the starting value, whether bits get reflected (reversed) going in and out, and a final XOR mask can all differ, and every combination produces a different checksum from identical input. The CRC RevEng catalogue lists over 100 registered parameter sets in total, from CRC-3 up to CRC-82, though the vast majority are obscure or vendor-specific. The 11 below cover the ones actually named in real specs and protocols:

If your device or spec names an exact variant (like "CRC-16/MODBUS" or "CRC-32/ISO-HDLC"), use that one — matching the checksum width alone isn't enough, since two 16-bit variants can disagree on every input. CRC-16/CCITT-FALSE and CRC-16/XMODEM share the same polynomial and differ only in the starting value, yet produce completely different output for the same data — a good example of how easy this is to get wrong from memory alone.

A worked check. The ASCII string "123456789" (the tool's default input) is the standard verification vector used across CRC implementations precisely because its correct output is well-published for every variant: CRC-32 should produce 0xCBF43926, CRC-16/MODBUS should produce 0x4B37, and CRC-64/XZ should produce 0x995DC9BBDF1939FA. If you're implementing a CRC in your own code, checking it against this string first catches most polynomial, bit-order, or init-value mistakes immediately.

What CRC is not. It detects accidental corruption — noise on a wire, a dropped bit, a torn write — reliably and cheaply. It is not a security checksum: an attacker who wants to tamper with data can trivially recompute a matching CRC for their modified version, since the algorithm is simple, fast, and has no secret key. For tamper-evident or cryptographic integrity checks, use the hash generator (SHA-256, etc.) or, for a keyed check, the HMAC generator. To verify a downloaded file hasn't been corrupted, see the file checksum tool; for raw byte/base conversions, the binary translator or number base converter.

Frequently asked questions

Why do different tools give different CRC-16 results for the same data?

"CRC-16" isn't one algorithm — different variants (CCITT-FALSE, MODBUS, XMODEM, etc.) use different polynomials, initial values, and bit-reflection settings, all producing different checksums from the same input. Make sure you match the exact variant your protocol or device expects.

What does "123456789" as the default input mean?

It's the standard CRC check string used to verify an implementation — a correct CRC-32 implementation should produce 0xCBF43926 for the ASCII bytes "123456789", for example.

What's the difference between the Text and Hex bytes input modes?

Text mode encodes your input as UTF-8 bytes (so "AB" becomes the two bytes 0x41, 0x42). Hex bytes mode lets you specify raw byte values directly, like "41 42" or "4142", useful for testing binary protocol frames.

Is CRC the same thing as a hash like MD5 or SHA-256?

They're related but serve different purposes. Both produce a fixed-size fingerprint of input data, but CRC is optimized to be fast and to reliably catch accidental bit errors, while cryptographic hashes like SHA-256 are designed so that no one can feasibly find two different inputs producing the same output on purpose. Don't use CRC anywhere security matters.

Can two different pieces of data produce the same CRC?

Yes — a CRC's output has far fewer possible values than the input data it summarizes, so collisions are mathematically guaranteed to exist for some inputs. This is expected and fine for its purpose (catching random transmission errors); it's only a problem if someone is deliberately trying to fake a match.

Why does reflection (refin/refout) matter?

Some hardware transmits the least-significant bit of each byte first, others the most-significant bit first. "Reflection" flips the bit order to match that transmission convention before or after the CRC math, so the computed checksum lines up with what the receiving hardware expects. Getting this setting wrong is the most common reason a from-scratch CRC implementation doesn't match a reference value.

How many CRC algorithms are there in total?

The CRC RevEng catalogue — the standard reference — lists over 100 registered parameter sets spanning widths from 3 to 82 bits, but most are obscure or specific to one vendor's hardware. This tool covers the 11 you're actually likely to encounter named in a real spec, driver, or file format.

What's the difference between CRC-32 and CRC-32C?

Both are 32-bit, but they use different polynomials, so they produce different checksums for identical input. CRC-32C (the "Castagnoli" polynomial) has better error-detection properties for certain error patterns and is used in iSCSI, SCTP, and modern filesystems like ext4 and btrfs, while plain CRC-32 remains far more common in general-purpose file formats and Ethernet.

Is CRC-16/KERMIT the same as CRC-16/CCITT?

Confusingly, yes — "CRC-16/CCITT" is a commonly used alias for what this catalogue calls CRC-16/KERMIT, while "CRC-16/CCITT-FALSE" (a different init value) is a separate, unrelated variant despite the near-identical name. Always check the actual polynomial and init value against a known test vector rather than trusting a name alone.