CRC Calculator

What a CRC calculator is for

A cyclic redundancy check is an error-detecting code computed by treating your message as the coefficients of a polynomial and taking the remainder after dividing by a fixed generator polynomial. The remainder — the CRC — is appended to the data so a receiver can recompute it and detect transmission or storage errors. CRCs are everywhere in embedded and protocol work: Ethernet frames, USB packets, MODBUS RTU, CAN bus, ZIP/gzip archives, ISO 7816 smart-card transport, and countless proprietary radio and sensor frames.

The catch is that "CRC-16" or "CRC-32" alone does not pin down a value. A CRC variant is defined by six parameters — width, polynomial, initial value, input reflection, output reflection, and a final XOR — and changing any one of them yields a different result for the same bytes. This tool implements one generic bit-by-bit engine, parameterised by those six values and using BigInt internally, so widths from 3 to 64 bits all behave identically and correctly. It ships with 70+ named presets drawn from Greg Cook's well-known reveng catalogue, plus a fully custom mode.

When to use it

Reach for this tool when you are reverse-engineering or implementing a protocol and need to confirm exactly which CRC variant a device uses, when a checksum you computed in one language does not match another stack, or when you are validating firmware that appends a CRC trailer. Selecting a preset immediately recomputes that preset's documented check value — the CRC of the ASCII string 123456789 — and shows a pass/fail badge comparing the computed result against the catalogue figure, so you can trust the engine before trusting any other output. For a plain additive or XOR integrity byte instead of a polynomial CRC, the sibling LRC calculator and checksum tool are the right fit.

Input and output

Choose how your message is interpreted: Text is UTF-8 encoded to bytes; Hex bytes accepts pairs of hex digits with optional spaces, colons, or 0x prefixes; Binary bits accepts 0/1 in groups totalling a whole number of bytes. The result panel reports the byte count and the final CRC in three forms — hexadecimal (zero-padded to the register width), decimal, and binary — and the Copy button copies the hex value. Each render also prints the active six parameters so the result is self-documenting.

Common mistakes

• Quoting only the polynomial. Two variants can share a polynomial and still differ by reflection or final XOR. Always nail down all six parameters when reproducing a value elsewhere.
• Reflected vs normal polynomial form. Presets here use the normal (non-reflected, MSB-first) polynomial. If a datasheet lists the reversed form (for example 0xEDB88320 for CRC-32), do not type it directly — use the normal form 0x04C11DB7 and the RefIn/RefOut flags instead.
• Hashing the wrong bytes. Decide whether the CRC should cover the header, the payload, or both, and whether the existing trailer bytes are included. Feeding the wrong span is the most common cause of a "wrong" CRC.
• Treating a CRC as cryptographic. CRCs detect accidental errors, not tampering. An attacker can adjust data to keep any CRC intact. For authentication use a MAC such as CMAC instead.
• Endianness of the appended CRC. The CRC value here is a number; how a protocol serialises it (big- or little-endian) is separate. Check the endianness tool when laying the bytes into a frame.

Related tools