How is Adler-32 calculated?

Adler-32 keeps two running sums modulo 65521 (the largest prime below 2^16). Sum A starts at 1 and adds each byte; sum B adds the current A after every byte. The checksum is (B << 16) | A, giving a 32-bit value.

How can I check the result is correct?

The standard check string is the ASCII text "123456789", which produces 0x091E01DE. A single empty input produces 0x00000001, since A starts at 1 and B stays 0. Matching values confirm the implementation.

Is Adler-32 better than CRC-32?

Adler-32 is faster to compute than CRC-32 because it only does additions, but it is weaker for very short messages and detects fewer error patterns. It is used in zlib and PNG where speed matters and data is rarely tiny.

Is Adler-32 a cryptographic checksum?

No. Adler-32 detects accidental corruption only and is trivial to forge. Never use it for security, passwords, or integrity against deliberate tampering — use SHA-256 or BLAKE3 instead.

Why does Adler-32 use modulo 65521?

65521 is the largest prime below 2^16, so each sum still fits in 16 bits while the prime modulus distributes values more uniformly than a power-of-two would. The two 16-bit sums then pack into one 32-bit checksum.

What makes Adler-32 a rolling checksum?

Both sums are simple additions, so the checksum of a sliding window can be updated in constant time by subtracting the outgoing byte and adding the incoming one. rsync exploits this Adler-style rolling property to test block matches at every byte offset cheaply.

What is the Adler-32 Checksum Calculator?

Free Adler-32 checksum calculator (RFC 1950, used by zlib and PNG) for text or raw hex bytes, showing the combined value plus the A and B sums in hex and decimal. Runs entirely in your browser; nothing is uploaded. It runs free in your browser on Gera Tools, with nothing uploaded.

Adler-32 Checksum Calculator

Name: Adler-32 Checksum Calculator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

This tool computes the Adler-32 checksum of any text or raw hex bytes and shows the combined 32-bit value plus its two component sums, updating live. Adler-32 is the integrity check used inside the zlib (DEFLATE) stream format and PNG, chosen because it is very cheap to compute.

How the Adler-32 checksum is computed

Adler-32 (RFC 1950) maintains two 16-bit running sums modulo 65521, the largest prime below 2^16. Sum A is initialised to 1 and accumulates each input byte; sum B is initialised to 0 and accumulates the current value of A after every byte, so it weights earlier bytes more heavily. After all bytes are processed, the checksum is (B << 16) | A — B in the high 16 bits and A in the low 16 bits. Using a prime modulus spreads the values more evenly than a power-of-two modulus would.

Example and notes

Input	Adler-32 (hex)
(empty)	00000001
`123456789`	091e01de

So the check string 123456789 produces 0x091E01DE, and an empty input produces 0x00000001 because A starts at 1 and B remains 0. These are reliable reference values.

Where Adler-32 fits in practice

Adler-32 was designed by Mark Adler as a faster alternative to CRC-32 for use in the zlib library. Its speed advantage comes from using only additions and modulo operations — no bit-shifting or polynomial XOR — which makes it simpler to implement and faster on early processors without hardware CRC support. The cost is weaker error detection on very short messages, where the sum structure does not distribute values as evenly as a polynomial CRC does.

Where you encounter Adler-32 in the wild:

zlib streams — the DEFLATE compressed data format used inside ZIP files, gzip, and HTTP’s Content-Encoding: deflate includes an Adler-32 checksum over the uncompressed data.
PNG files — each IDAT chunk in a PNG is a zlib stream, so every PNG carries an Adler-32 internally, even though most people interact with PNG’s outer CRC-32 chunk checksum.
OpenDocument and OOXML — office file formats based on ZIP containers inherit Adler-32 through zlib.
Some network protocols and embedded firmware — where code size matters more than error-detection strength.

Tracing the algorithm by hand

Checksumming the three ASCII bytes abc (97, 98, 99) shows the whole algorithm:

Byte	A (starts at 1)	B (starts at 0)
`a` = 97	1 + 97 = 98	0 + 98 = 98
`b` = 98	98 + 98 = 196	98 + 196 = 294
`c` = 99	196 + 99 = 295	294 + 295 = 589

Neither sum reached 65521, so no modulo reduction fires. The result is (589 << 16) | 295 = 0x024D0127 — a value you can confirm against zlib’s adler32() in one line of Python: zlib.adler32(b"abc").

The trace also exposes Adler-32’s documented weakness on short inputs: after three bytes, A is at most 1 + 3×255 = 766, nowhere near filling its 16 bits. For messages under a few hundred bytes, large parts of the checksum space are simply unreachable, which is why RFC 3309 replaced Adler-32 with CRC-32c in SCTP after analysis showed inadequate error detection for small packets.

The rolling-checksum trick

Because both sums are plain additions, Adler-style checksums can be computed over a sliding window in O(1) per step: to slide one byte, subtract the outgoing byte from A, add the incoming byte, and adjust B by A_new − window_length × outgoing − 1. No polynomial checksum can do this as cheaply. This property — not raw speed — is why rsync’s block-matching algorithm uses an Adler-inspired rolling checksum to find matching blocks at every byte offset of a file, then confirms candidates with a stronger hash. If you are building deduplication, delta-sync, or content-defined chunking, this rolling property is the reason to reach for an Adler-family checksum.

Adler-32 vs. CRC-32 vs. MD5 — which should you use?

Checksum	Speed	Error detection	Secure?	Best use
Adler-32	Very fast	Moderate (weak on short data)	No	zlib, PNG (already embedded)
CRC-32	Fast	Strong (burst errors)	No	File integrity, Ethernet, ZIP
MD5	Slower	Excellent (cryptographically broken)	No	Non-security deduplication
SHA-256	Slowest of these	Excellent	Yes	Security, digital signatures

Adler-32 is faster than CRC-32 but weaker on short data and is not cryptographic. Use it for quick accidental-corruption detection, never for security. Everything is computed locally in your browser; nothing is uploaded.

Sources and references

RFC 1950 — ZLIB Compressed Data Format (Adler-32 specification) — the authoritative definition, including the modulo-65521 rule
zlib home page and manual — the reference library where Adler-32 is used in the DEFLATE stream
RFC 2083 — PNG specification — how PNG embeds zlib (and therefore Adler-32) in IDAT chunks

Maintained by the Gera Tools editorial team. The reference vectors (123456789 → 0x091E01DE, empty → 0x00000001) come from RFC 1950; use them to verify the tool. Adler-32 is not a security hash. Last reviewed 2026-07-02.