Adler-32 Checksum
Compute the zlib Adler-32 checksum of text or hex.
How to use
- 1 Choose whether your input is UTF-8 text or hex bytes.
- 2 Type or paste the data to checksum.
- 3 Read the Adler-32 value in hex and decimal, with the A and B sums.
- 4 Toggle uppercase if needed and copy the result.
About Adler-32 Checksum
The Adler-32 Checksum tool computes the Adler-32 value of any text or sequence of bytes, the same lightweight checksum that zlib stores at the end of every compressed stream (RFC 1950).
Adler-32 was designed by Mark Adler as a faster alternative to a full CRC: it maintains two running 16-bit sums, A and B, both taken modulo 65521 — the largest prime under 2^16 — and combines them into a single 32-bit value.
The result is cheaper to calculate than CRC32, which makes it popular inside compression and rsync-style tooling, at the cost of weaker error detection on very short inputs.
Paste UTF-8 text and the tool encodes it to bytes before checksumming, or switch to hex mode to checksum raw bytes written as pairs like "de ad be ef".
You get the checksum as a zero-padded eight-digit hex string and as an unsigned decimal, and because seeing the internals is often useful when debugging a stream, the individual A (low) and B (high) sums are shown alongside.
An uppercase toggle and one-click copy make it easy to drop the value wherever you need it.
Everything is calculated locally in your browser using plain JavaScript — your input is never uploaded or logged — so it is safe for private data and keeps working offline once the page has loaded.
FAQ
How does Adler-32 differ from CRC32?
Adler-32 sums bytes into two modular accumulators, which is faster to compute than CRC32's polynomial division. CRC32 catches more error patterns, especially on short inputs, so Adler-32 trades a little robustness for speed.
Why 65521?
It is the largest prime number below 2^16. Using a prime modulus spreads the sums more evenly and improves the checksum's error-detection properties.
What is the checksum of empty input?
It is 0x00000001, because the A accumulator starts at 1 and B starts at 0, and no bytes are processed.