About

Adler-32 is a checksum algorithm defined in RFC 1950, used internally by zlib and gzip for fast data integrity verification. It operates on two 16-bit accumulators, A and B, reduced modulo 65521 (the largest prime below 2¹⁶). Compared to CRC-32, Adler-32 trades collision resistance for computation speed - roughly 5-8× faster on typical hardware. This makes it suitable for streaming compression but insufficient for cryptographic or archival deduplication tasks where collision probability matters.

Miscalculating a checksum during data transfer or archive validation can silently pass corrupted payloads. This tool computes Adler-32 for arbitrary text (UTF-8 encoded) and binary files, processing in optimized blocks of 5552 bytes to defer modulo operations. Note: Adler-32 has a known weakness with short messages (under 128 bytes) where collision rates exceed CRC-32. For cryptographic integrity, use SHA-256 instead.

Formulas

The Adler-32 checksum is computed from two 16-bit sums over the input byte sequence. Given a byte stream D₁, D₂, …, D_n:

A = 1 + n∑i=1 D_i mod 65521

B = n∑i=1 A_i mod 65521

Adler32 = B × 65536 + A = (B << 16) | A

Where A = running byte sum initialized to 1. B = running sum of all intermediate A values. D_i = the i-th byte of input data. 65521 = the largest prime less than 2¹⁶, chosen to keep intermediate sums within 32-bit integer range. The block size of 5552 bytes allows deferring modulo: the maximum possible value of A after 5552 iterations of adding 255 is 5552 × 255 = 1,415,760, well within 32-bit range.

Reference Data

Algorithm	Output Size	Speed (Relative)	Collision Resistance	Standard	Use Case
Adler-32	32 bit	Very Fast	Low	RFC 1950	zlib, gzip streams
CRC-32	32 bit	Fast	Moderate	ISO 3309	Ethernet, ZIP, PNG
CRC-32C	32 bit	Fast (HW)	Moderate	RFC 3720	iSCSI, ext4
Fletcher-16	16 bit	Very Fast	Low	RFC 1146	Legacy protocols
Fletcher-32	32 bit	Very Fast	Low	-	Embedded systems
MD5	128 bit	Moderate	Broken	RFC 1321	Legacy file verification
SHA-1	160 bit	Moderate	Broken	FIPS 180-4	Git (legacy), TLS (deprecated)
SHA-256	256 bit	Slow	Strong	FIPS 180-4	TLS, Bitcoin, code signing
SHA-512	512 bit	Slow	Strong	FIPS 180-4	High-security applications
xxHash32	32 bit	Extremely Fast	Low	-	Hash tables, dedup
xxHash64	64 bit	Extremely Fast	Moderate	-	Large-scale dedup
MurmurHash3	32/128 bit	Extremely Fast	Low	-	Hash tables, Bloom filters
FNV-1a	32/64 bit	Fast	Low	-	Hash tables, DNS
BLAKE2b	256 bit	Fast	Strong	RFC 7693	Password hashing, file integrity
CityHash	64/128 bit	Extremely Fast	Moderate	-	Google internal systems

Frequently Asked Questions

The modulus 65521 is the largest prime number less than 2¹⁶ (65536). Using a prime modulus ensures a more uniform distribution of checksum values across the output space. A power-of-two modulus would create systematic biases where certain bit patterns produce disproportionately more collisions. The prime choice improves avalanche behavior - small input changes affect more output bits.

CRC-32 detects all single-bit, double-bit, and odd-number-of-bit errors, plus burst errors up to 32 bits. Adler-32 lacks these deterministic guarantees. For messages shorter than approximately 128 bytes, Adler-32 has measurably higher collision rates than CRC-32. The tradeoff is speed: Adler-32 requires only additions and modulo operations, while CRC-32 requires XOR with a polynomial lookup table. In zlib, Adler-32 checksums the uncompressed data stream while DEFLATE handles byte-level error patterns.

The value 5552 is the largest n such that 255 × n × (n + 1) / 2 + (n + 1) × (65521 − 1) remains below 2³² − 1. This means both A and B accumulators stay within 32-bit unsigned integer bounds for 5552 consecutive byte additions without any intermediate modulo. This avoids expensive division operations inside the inner loop.

Adler-32 can detect most byte-swap errors because B is position-dependent - it weights earlier bytes more heavily (they contribute to more cumulative A additions). Swapping two adjacent bytes changes B by the difference of those byte values. However, if two swapped bytes have identical values, the checksum remains unchanged. CRC-32 handles this case better due to its polynomial feedback structure.

For casual integrity checks (detecting accidental corruption), Adler-32 is adequate and fast. For archival or security-critical verification, it is insufficient. With only 32 bits of output, the birthday bound gives a 50% collision probability at approximately 2¹⁶ (65536) distinct messages. For file downloads, SHA-256 is the standard. Adler-32 is best reserved for real-time streaming contexts where it was designed to operate, such as inside zlib compressed streams.

For an empty byte sequence, A remains at its initial value of 1 and B remains at 0. The resulting checksum is (0 << 16) | 1 = 0x00000001 (decimal 1). This is the defined initial value per RFC 1950. Any tool that returns 0 for empty input has an incorrect implementation.