CRC Calculator — CRC-8, CRC-16 and CRC-32

CRC-8, CRC-16 (CCITT, Modbus, XMODEM) and CRC-32 over hex or ASCII input, with the polynomial and shift steps explained.

Example: The CRC-32 (zlib / PKZIP) of 9 bytes is 0xCBF43926.

Inputs

Data

In hex mode, separators are ignored: 01 02 03, 0x01,0x02 and 010203 are the same.

Input format

Algorithm

Result

CRC-32 (zlib / PKZIP)

0xCBF43926

Decimal: 3421780262
Big-endian bytes: CB F4 39 26
Little-endian bytes: 26 39 F4 CB
Bytes checksummed: 9

The CRC-32 used by zip, gzip, PNG and Ethernet.
If your CRC matches this but the device rejects it, the mismatch is usually byte order or which bytes are included, not the algorithm. Check whether the address and function fields are inside the checksummed range.

Parameters of this variant

Parameter	Value
Width	32 bits
Polynomial	0x04C11DB7
Initial value	0xFFFFFFFF
Reflect input	yes
Reflect output	yes
Final XOR	0xFFFFFFFF
Check value of “123456789”	0xCBF43926

/* generated by urdb.io/tools/crc-calculator */
uint32_t crc_update(uint32_t crc, const uint8_t *data, size_t len) {
    for (size_t i = 0; i < len; i++) {
        crc ^= data[i];   /* reflected variant: XOR into the low byte */
        for (int b = 0; b < 8; b++) {
            crc = (crc & 1) ? (crc >> 1) ^ 0xEDB88320 : (crc >> 1);
        }
    }
    return crc;
}

/* init 0xFFFFFFFF, final XOR 0xFFFFFFFF */

Check it against real silicon

Chiprun runs your firmware on an emulated microcontroller and hands back the UART output, so you can confirm these numbers rather than trusting them.

Chiprun docs

Formula

shift left, XOR the polynomial whenever the top bit was set

Worked example

The CRC-32 (zlib / PKZIP) of 9 bytes is 0xCBF43926.

register = init
register = 0xFFFFFFFF
0xFFFFFFFF
for each byte: XOR in, then shift 8 times
polynomial 0x04C11DB7, input reflected
9 bytes processed
On each shift, if the bit shifted out was 1, XOR the polynomial back in.
result = reflect(register) XOR xorOut
reflected, XOR 0xFFFFFFFF
0xCBF43926

Frequently asked questions

Why do two CRC calculators give different answers for the same data?

Because 'CRC-16' is not one algorithm. The same polynomial with a different initial value, or with the input bits reflected, produces a completely different result. CRC-16/MODBUS and CRC-16/ARC share a polynomial and still disagree. Always match the variant, not just the width.

What is the check value for?

It is the CRC of the ASCII string “123456789”, published for every standard variant. Running your own implementation against it is the fastest way to confirm you have the polynomial, initial value, reflection and final XOR all correct.

My CRC matches this tool but the device still rejects my frame.

Almost always byte order or coverage. Modbus RTU sends the CRC low byte first, which looks backwards next to the written value. And protocols differ on which fields are inside the checksummed range — the address and function bytes usually are.

Does a CRC protect against tampering?

No. A CRC detects accidental corruption — noise, bit flips, truncation — and is very good at it. It offers no protection against deliberate modification, because anyone can recompute it. For that you need a MAC or a signature.

Related tools

Modbus RTU Frame Builder

Build and decode Modbus RTU frames with automatic CRC, function-code reference and error decoding.

Firmware

Hex, Binary & Decimal Converter

Convert between hex, binary, decimal, octal and ASCII, with width-aware bit grids and endianness swapping.

Firmware

Base64 & Hex Blob Converter

Convert firmware blobs between base64, hex and raw bytes, with size and checksum readouts.

Firmware

Intel HEX & SREC Viewer

Parse Intel HEX and Motorola SREC files, verify checksums and view the resulting memory map.

Firmware

Bitwise Operation Calculator

AND, OR, XOR, NOT and shifts with a live bit grid so you can see exactly which bits moved.

Firmware

IEEE 754 Float Converter

Convert between decimal, hex and binary float32/float64, with the sign, exponent and mantissa fields broken out.

Firmware