Introduction
Debugging a zlib stream or verifying gzip integrity? Adler-32 is the checksum algorithm defined in RFC 1950 for zlib-compressed data. It is simpler and faster than CRC32 but slightly less reliable at detecting errors. This Adler-32 calculator computes the checksum for any text input, producing the same 8-character hex value you would find in a zlib header or gzip footer. Paste your data and get the result instantly. No data leaves your browser.
What this tool does
- Computes the Adler-32 checksum as defined in RFC 1950, used by zlib and gzip.
- Outputs an 8-character hexadecimal string representing the 32-bit checksum.
- Processes input as UTF-8 bytes, matching standard library implementations.
- Updates the checksum in real time as you type.
- Runs entirely client-side with no network requests.
How this tool works
Type or paste text into the input field. The tool encodes the text as UTF-8 bytes and computes two running sums: s1 (sum of all bytes, starting at 1, modulo 65521) and s2 (sum of all s1 values, starting at 0, modulo 65521). The final checksum is (s2 << 16) | s1, displayed as an 8-character lowercase hex string. Copy it with one click.
How Adler-32 works
Adler-32 was designed by Mark Adler, co-author of the zlib compression library and the gzip format. It is specified in RFC 1950 (ZLIB Compressed Data Format Specification) and used as the default checksum in zlib streams.
The algorithm maintains two 16-bit accumulators: - s1 starts at 1 and accumulates the sum of each byte, modulo 65521. - s2 starts at 0 and accumulates the running sum of s1, modulo 65521.
The final 32-bit checksum is `(s2 << 16) | s1`. The modulus 65521 is the largest prime number that fits in 16 bits, chosen to maximize the period before the sums wrap around.
Adler-32 is faster than CRC32 because it uses simple addition and comparison instead of table-driven polynomial division. However, it is weaker at detecting burst errors. For messages shorter than 55 bytes, Adler-32 can detect fewer error patterns than CRC32. For longer messages, the difference is negligible in practice.
The zlib format uses Adler-32 for the stream checksum (the last 4 bytes of a zlib stream). The gzip format (RFC 1952) uses CRC32 for the footer instead, but the deflate compressed data within gzip can be wrapped in a zlib stream that uses Adler-32. The PNG image format also uses Adler-32 for its zlib-compressed image data chunks.
How to use this tool
- Type or paste the text you want to checksum into the input field.
- The Adler-32 value appears instantly as an 8-character hex string.
- Click the Copy button to copy the checksum to your clipboard.
- Compare the result against a known Adler-32 value to verify data integrity.
Real-world examples
Verifying a zlib stream checksum
A zlib-compressed stream ends with a 4-byte Adler-32 checksum of the uncompressed data. After decompressing a zlib stream, a developer computes Adler-32 over the decompressed data and compares it against the last 4 bytes of the stream. Input: the decompressed text. Output: an 8-character hex string like '00640105' that should match the stream's checksum.
PNG image data verification
PNG stores image data in zlib-compressed IDAT chunks. The zlib stream within those chunks uses Adler-32 for integrity. A developer extracting raw image data from a PNG computes Adler-32 over the decompressed pixel data to verify it matches the zlib stream's checksum.
Comparing Adler-32 with CRC32
A developer choosing between Adler-32 and CRC32 for a custom protocol hashes the same input with both. Input: 'Wikipedia'. Adler-32 output: '11e60398'. CRC32 output: '22a200e7'. Both are 32-bit values but computed with different algorithms. Adler-32 is faster but slightly weaker for short messages.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Adler-32 | O(n), two modular sums | zlib, PNG, deflate |
| CRC32 (IEEE 802.3) | O(n), table-driven polynomial | Ethernet, gzip, PNG |
| Fletcher-32 | O(n), two modular sums | TCP, ADCCP |
| CRC64 | O(n), table-driven, 64-bit | XZ archives, database engines |
Limitations or considerations
Adler-32 is a checksum, not a cryptographic hash. It detects accidental corruption but provides no security against intentional tampering. For messages shorter than 55 bytes, Adler-32 detects fewer error patterns than CRC32 because the modulus operation does not fully mix the bits. For security-sensitive integrity verification, use SHA-256 or BLAKE2. This tool processes text input only and cannot directly checksum binary files.
Frequently asked questions
Why is Adler-32 faster than CRC32?
Adler-32 uses simple integer addition and comparison with a modulus, while CRC32 uses table-driven polynomial division with XOR operations. On modern processors, addition is cheaper than table lookups, making Adler-32 faster for most input sizes.
What is the modulus 65521?
65521 is the largest prime number that fits in 16 bits (2^16 - 15). Using a prime modulus maximizes the period of the running sums before they repeat, which improves error detection. The choice is specified in RFC 1950.
Does gzip use Adler-32?
No, gzip uses CRC32 for its footer checksum (RFC 1952). However, the deflate compressed data inside gzip can be wrapped in a zlib stream, which uses Adler-32. PNG uses zlib internally, so PNG image data is checksummed with Adler-32.
Can Adler-32 detect all single-bit errors?
Yes, Adler-32 detects all single-bit errors. However, for very short messages (under 55 bytes), it may miss some multi-bit errors that CRC32 would catch.
Conclusion
This Adler-32 checksum tool computes the RFC 1950 checksum used by zlib and PNG. It runs entirely in your browser and updates instantly. For related checksum tools, try the Fletcher-32 Checksum, the CRC64 Calculator, or the Checksum Calculator (which includes CRC32).