CRC guides

A cyclic redundancy check catches accidental corruption in transmitted data. Two calculators disagree unless every parameter, not just the polynomial, matches.

CRCs, additive checksums, cryptographic hashes, and MACs all detect data changes — but only a MAC can prove authenticity, not just accidental corruption.

A decision guide for picking a CRC algorithm by protocol, file format, and industry — and what to default to when nothing external dictates the choice.

Quick definitions for CRC terms the parameter guides don't spell out — notation, verification terms, and error-detection theory.

CRC polynomial notation explained: the implicit top bit, and why normal and reflected forms of the same polynomial look different but define one CRC model.

See how the starting register value (Init) changes CRC results before any data is processed, and why many standards default to all zeros or all ones.

Understand what RefIn and RefOut actually control — bit order per byte, register shift direction, and the most common double-reflection mistake.

Learn when the final XOR (XorOut) is applied to the CRC register, and why a raw internal remainder can differ from the published, transmitted CRC value.

Every CRC model publishes a check value for ASCII '123456789' — use it to verify width, polynomial, Init, reflection, and XorOut before trusting real data.

Understand the residue constant and how a complete codeword — message plus its CRC — can be verified in one pass without separating data from checksum.

Work through Width, Poly, Init, RefIn/RefOut, XorOut, input encoding, and byte order in order to find why two calculators disagree.

CRC-16/CCITT, CRC-16/ARC vs MAXIM-DOW, and CRC-32/JAMCRC vs ISO-HDLC show why a shared name is not a shared result — and when an alias really is identical.

CRC work often confuses three ordering questions: input byte order, RefIn bit order per byte, and how the final CRC bytes are serialized on the wire.

Which CRC Modbus RTU uses, how the 2-byte CRC is appended to a frame in low-byte-first order, and how to compute it step by step with worked examples.

How CAN FD extends classic CAN error detection with CRC-17 and CRC-21, and why this calculator cannot compute either one directly.

How AUTOSAR End-to-End protection uses CRC-8/AUTOSAR for short signals and CRC-32/AUTOSAR for larger PDUs, and how the two profiles' parameters differ.

Why iSCSI, SCTP, and several NVMe transports use the Castagnoli CRC32C polynomial instead of Ethernet CRC-32, and how to verify an implementation.

How the seven catalogued CRC-64 models differ, and which one applies to XZ, Redis, .cab files, NVMe, and general high-integrity use.

Every AUTOSAR and CAN CRC model in the catalog — CRC-8/AUTOSAR, CRC-32/AUTOSAR, CAN FD bitstream CRCs, and legacy CRC-8/SAE-J1850 — gathered by network layer.

Every storage-oriented CRC model in the catalog — CRC32C, the seven CRC-64 variants, and the SCSI/optical-media CRCs — gathered in one place.

Every cellular, short-range wireless, and radio CRC model in the catalog — Bluetooth, GSM, DECT, CDMA2000, WCDMA, LTE, UMTS — gathered in one place.