Which CRC algorithm should I use?

For most projects this is not actually an open question. If code needs to interoperate with an existing protocol, file format, or piece of deployed hardware, that system already defines exactly which CRC model it expects, down to the initial value and final XOR — the task is to identify and match that model, not to choose one. Guessing based on width or popularity produces a checksum that looks plausible and fails every real comparison.

The question "which algorithm should I use" only has a free answer when something new is being designed — a new internal protocol, a new file format, a new device link — with no existing consumer to match. The reference tables below cover the first, far more common case; the last section covers the second.

When a name is already known — a protocol, a file extension, a transport — match it to the model below rather than assuming a generic CRC-16 or CRC-32 is close enough.

Industry-specific stacks frequently define their own CRC models rather than reusing a general-purpose one, precisely because "CRC-16" or "CRC-32" alone does not pin down a unique checksum.

A 32-bit CRC has a fixed collision probability regardless of message length, and for very large files or long-lived datasets that probability becomes large enough to matter — doubling the width to 64 bits reduces the chance of an undetected multi-bit error by roughly 2^32. Use the CRC-64 variant a target format actually specifies rather than a generic one; the CRC-64 guide compares all seven catalogued models and covers which applies to .xz, Redis, .cab files, and NVMe.

If nothing external pins down the model — a new internal protocol, a new file format, a new device link — the decision comes down to a few practical questions rather than one universal answer.