Hashing
Adler-32 checksum calculator
Adler-32 is the checksum zlib stores for uncompressed data in its stream format: a 32-bit value built from two rolling sums and rendered here as 8 uppercase hex characters. Developers meet it when debugging compressed streams, parsing zlib containers, or porting checksum code between languages. It is cheap to compute, which is why streaming formats adopted it, but its simple math misses some small changes that CRC-32 would catch.
How to use Adler-32
- Open Adler-32 in the Toolbox101 app.
- Paste the text or byte stream you want checked into the
Inputbox. - The 8-character uppercase checksum appears in the
Outputbox as you type. - Click
Copyto put the checksum on your clipboard for comparison.
Worked example
Adler-32 returns the output below for this input.
Input
The quick brown fox jumps over the lazy dogOutput
5BDC0FDACheck it yourself: open Adler-32 and enter the same input.
Frequently asked questions
What is Adler-32 used for in practice?
Adler-32 is the checksum the zlib stream format stores at its end: decompressors recompute it over the uncompressed bytes and compare it with that stored 32-bit value. Libraries expose it as zlib.adler32 in Python, adler32() in zlib in C, and equivalents in most languages, so it shows up in ported and mixed-language tooling.
Why does Adler-32 miss some changes that CRC-32 catches?
Adler-32 sums bytes with two 16-bit accumulators wrapped modulo 65521, so it is nearly linear: swapping two bytes, or shifting a run of bytes by a constant offset, can leave both sums unchanged. CRC-32's polynomial division scatters such patterns better. Neither is cryptographic; for deliberate tampering use SHA-256.
When should I pick Adler-32 over CRC-32?
Rarely, on the merits: CRC-32 detects more error patterns and is the usual choice for new formats. Adler-32 wins only where compatibility matters: the format already stores it, or a peer implementation requires it. If you control the format and tampering is a concern, use SHA-256 instead.
Why is my Adler-32 output always 8 characters?
The checksum is a 32-bit value and the tool prints it as 8 uppercase hex characters, zero-padded. A short input can give a small number, such as 00000001 for the empty string, and the padding keeps the width fixed. The value is the same number zlib reports for the same bytes, written in hex.