Encoding and security guides
CRC32 mismatch: variant, bytes and unsigned output
Use a known test vector to distinguish IEEE CRC32 from CRC32C and formatting differences.
Name the variant
CRC32 is a family name rather than a complete algorithm specification. CRC32C uses a different polynomial from the IEEE CRC32 used by Gzip.
Nav Tools offers IEEE-style CRC32 and Adler32; it does not expose a CRC32C calculation mode.
ASCII bytes of "123456789":
IEEE CRC32 → cbf43926
CRC32C → e3069283Agree on the input bytes
A newline, UTF-8 BOM or different character encoding changes the checksum. The label shown by a file viewer is not the input.
Use the nine ASCII digits without a trailing newline as a shared fixture. For file protocols, calculate over the required byte range.
Normalize representation before comparing
A 32-bit result can be printed as signed decimal, unsigned decimal or hexadecimal. Negative signed output can represent the same bits.
Compare a fixed-width eight-digit hex value or explicitly convert to unsigned 32-bit output before declaring a mismatch.
0xcbf43926 >>> 0 → 3421780262
0xcbf43926 | 0 → -873187034Do not use a CRC as authentication
CRC detects many accidental changes but is not designed to resist an attacker deliberately modifying a message.
After interoperability is fixed, use the protocol's authenticated integrity mechanism when adversarial tampering matters. A matching CRC alone cannot authenticate a sender.