What is Adler-32 used for?

Adler-32 is the integrity check embedded in the zlib data format (RFC 1950), which wraps DEFLATE streams used by PNG, gzip's library, and many protocols. It is faster to compute than CRC-32 but slightly weaker for short inputs.

How is the value structured?

Adler-32 keeps two running sums modulo 65521. Sum A accumulates the bytes (starting at 1), and sum B accumulates A (starting at 0). The final 32-bit value is (B shifted left 16) OR A, which this tool also shows broken out.

Why does an empty string give 00000001?

Sum A is initialised to 1 and sum B to 0. With no bytes processed, A stays 1 and B stays 0, so the result is (0 << 16) | 1 = 1, shown as the hex 00000001.

No. Like CRC-32 it only detects accidental corruption, not deliberate tampering. It is also weak for very short messages. Use a cryptographic hash such as SHA-256 for any security purpose.

Why 65521 specifically?

65521 is the largest prime below 65536 (2^16). Using a prime modulus improves the error-detection properties of the modular sums while keeping each sum within 16 bits.

What is the Adler-32 Checksum Calculator?

Compute the Adler-32 checksum of any text per the zlib / RFC 1950 specification. Returns the 8-digit hex value, decimal form, and the two component sums A and B, all computed locally in your browser over the UTF-8 bytes of the input. 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/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Adler-32 is a checksum algorithm invented by Mark Adler for the zlib compression library. It trades a little error-detection strength for speed, and appears as the trailing integrity check in every zlib-wrapped DEFLATE stream — which means it lives inside every PNG file, every gzip-compressed HTTP response, and any other format that uses the zlib wrapper. This tool computes it over the UTF-8 bytes of your text.

Where Adler-32 appears

Format / Protocol	Adler-32 location
PNG	Embedded in zlib IDAT chunks
HTTP gzip / Content-Encoding	zlib stream trailer
zlib streams (RFC 1950)	Final 4 bytes of the stream
Java `.jar` manifest entries	Some legacy tools

Unlike CRC-32, which appears in standalone GZIP files, Adler-32 is specifically the check value for zlib-wrapped streams.

How it works

Adler-32 maintains two 16-bit running sums, both taken modulo the prime 65521:

A = 1, B = 0
for each byte b:
    A = (A + b)  mod 65521
    B = (B + A)  mod 65521
result = (B << 16) | A

Sum A is a simple running total of the byte values; sum B accumulates all intermediate A values, which makes the result sensitive to byte order — not just which bytes are present. The 32-bit output packs B into the high 16 bits and A into the low 16 bits.

Reference values for verification

Empty string → 00000001 (A=1, B=0 with no bytes processed)
The string "Wikipedia" → 11E60398 (well-known test vector)

Confirm your implementation matches these before using Adler-32 in a file format or protocol.

Strengths and weaknesses

Fast. Adler-32 requires only two additions and one modulo operation per byte, with no lookup table needed — which was a meaningful advantage when zlib was designed in the mid-1990s and table-driven CRC was slower on small embedded processors.

Weak on short inputs. The additive structure means many short messages produce the same checksum, especially strings consisting of the same repeated byte. CRC-32 has better collision resistance for short inputs, which is why it is preferred in file formats like ZIP that check small blocks.

Not cryptographic. As with any non-keyed checksum, Adler-32 detects accidental corruption, not deliberate tampering. Use SHA-256 or another cryptographic hash for any security application.

Encoding matters. The checksum is computed over UTF-8 bytes. A non-ASCII character such as an em dash or accented letter expands to multiple bytes, changing the result compared with what you would get from a Latin-1 or UTF-16 encoding of the same visible text.