Checksums are short fingerprints computed from a larger input, designed to detect whether the data has been changed. Non-cryptographic checksums are fast, simple, and designed for catching accidental corruption — bit flips in transit, storage errors, file transfer glitches — rather than deliberate tampering. This tool computes four classic non-cryptographic checksums at once: CRC-32, CRC-16 (CCITT-FALSE), Adler-32, and Fletcher-32.
Paste text or upload a small file and every algorithm runs in parallel. Reference vectors are verified against published test values so you can trust the output.
The four algorithms
- CRC-32 — IEEE 802.3 polynomial (0xEDB88320 reflected). The standard in ZIP, gzip, PNG, Ethernet frames, and almost every file format that includes an integrity check. Strong error detection for short inputs, fast enough to compute in streaming on commodity hardware.
- CRC-16 CCITT-FALSE — polynomial 0x1021, initial value 0xFFFF, no reflection, no final XOR. Common in XMODEM, Bluetooth headers, and ISO/IEC 14443 RFID. One of several CRC-16 variants; this tool implements only CCITT-FALSE.
- Adler-32 — Mark Adler’s algorithm from zlib. Two running sums
aandb, both taken mod 65521 (the largest prime below 2^16). Slightly faster than CRC-32 on short inputs, used in zlib/deflate stream headers for exactly that reason. Has known collision weakness on very short strings — avoid for anything where two similar short inputs might need to be distinguished. - Fletcher-32 — John Fletcher’s algorithm (1982), similar structure to Adler-32 but with modulus 65535 (= 2^16 − 1) and slightly different accumulation. Used in the TCP stack and some older protocols. Performs similarly to Adler-32 in practice; the differences are mostly academic.
The math, briefly
CRC-32 treats the input as a polynomial over GF(2) — the Galois field with two elements, where addition is XOR and multiplication is AND. The checksum is the remainder after dividing that polynomial by the generator polynomial 0xEDB88320 (reversed). The reversed form lets you process the message least-significant-bit first, which happens to be how bytes come off the wire in most protocols, so the implementation is efficient. A precomputed 256-entry lookup table reduces the inner loop to one table lookup and one XOR per byte.
Adler-32 is just two running sums:
Where $a_i$ is the value of $a$ after processing byte $i$. The modulus 65521 is the largest prime below 2^16 — a prime modulus gives better error-detection properties than the obvious 2^16 choice. Starting $a$ at 1 instead of 0 lets the algorithm distinguish an empty input from a single zero byte.
Fletcher-32 uses the same structure but with modulus 65535 (2^16 − 1). The non-prime modulus is slightly weaker mathematically than Adler’s prime, but the implementation is a little faster because the modulo can be computed without division.
CRC-16 is structurally identical to CRC-32 at the bit level, just using a shorter polynomial.
Example: verifying a ZIP download
A ZIP file’s internal file listing includes a CRC-32 for every entry. When you extract, the unzip tool recomputes the CRC-32 from the decompressed bytes and compares it to the stored value — if they don’t match, the file was corrupted somewhere along the way. This is why you occasionally see “CRC check failed” errors on damaged archives. CRC-32 is strong enough to catch essentially any realistic random corruption pattern: bit flips, truncation, byte-boundary shifts. It is not strong enough to prevent deliberate tampering — an attacker can trivially construct two different files with the same CRC-32.
For integrity against tampering, use SHA-256 or a signed hash. The CRC is just for “did this file survive transit in one piece”.
Example: reference vectors
Every algorithm has canonical test vectors you can use to verify a new implementation:
- CRC-32 of
abcis0x352441c2 - CRC-32 of
123456789is0xcbf43926 - CRC-16 CCITT-FALSE of
123456789is0x29b1 - Adler-32 of
Wikipediais0x11e60398
If your implementation matches these, you probably have the algorithm right. If it doesn’t, you likely have the initial value or the final XOR wrong — that’s the most common source of CRC bugs. This tool passes all these vectors in its test suite.
What this tool does not do
It does not compute cryptographic hashes — SHA-1, SHA-256, SHA-384, and SHA-512 are handled by the dedicated hash generator. Use that instead if you need collision resistance or authentication, not this.
It does not implement every CRC variant that exists — there are dozens of CRC-16 and several dozen CRC-32 variants, all differing in polynomial, initial value, reflection, and XOR-out. This tool ships CRC-32 IEEE (the ZIP/gzip variant) and CRC-16 CCITT-FALSE (the XMODEM variant). If you need a different one, the math is in the source and easy to adapt.
It does not support very large files — there’s a 16 MB limit on file uploads to keep browser memory sane. For larger files, use a command-line tool like cksum or crc32 that can stream the input.