Adler-32 and Fletcher Calculator

Two simple checksum families keep turning up in low-level code: Adler-32, defined by Mark Adler for the zlib compression library, and the Fletcher checksums, described by John G. Fletcher in 1982. Both are cheaper than a CRC and both rely on the same trick, two running sums. This page calculates Adler-32 and Fletcher-16, -32 and -64 for any data at once.

How Adler-32 works

The algorithm keeps two 16-bit values. A starts at 1 and gets each data byte added; B starts at 0 and gets A added after every byte. Both are reduced modulo 65521, the largest prime that fits in 16 bits. The final checksum puts B in the high half and A in the low half. Because A and B start small and grow by at most 255 per byte, a very short message leaves both sums far below the modulus, so few bits change between similar short inputs. That is the known weakness of Adler-32 on small messages.

A worked example

The Sample button loads the nine bytes of the word Wikipedia, the example used in the algorithm’s reference article. The page reports Adler-32 as 11e60398, in decimal 300286872. Working it out by hand: the nine byte values add up to 919, so A is 1 + 919 = 920, which is 0x0398. After each byte B adds the current A, and the nine running values 88, 193, 300, 405, 517, 618, 718, 823 and 920 add up to 4582, which is 0x11E6. Joined, B then A, they make 0x11E60398. The same data gives Fletcher-16 ee9a, Fletcher-32 b7dda1f8 and Fletcher-64 0f0b0748d2cfcf28 on this page, with a length of 9 bytes.

Fletcher differences

Fletcher uses the same two sums but takes a word at a time and reduces modulo one less than a power of two, so the sums are those of a one’s complement addition. Fletcher-16 works on bytes, Fletcher-32 on 16-bit words and Fletcher-64 on 32-bit words. Implementations disagree about the byte order of words and about padding. This page reads little-endian words and pads the last word with zeros. If a datasheet’s value does not match, test the other conventions by padding or reordering your input as hex.

Input and output

You can enter text, hex bytes or Base64, or open a file. Each result is shown in hexadecimal, and Adler-32 also in decimal, with a copy button. Text is converted to UTF-8 first, so non-ASCII characters add more than one byte each.

Limits

Neither family is a security tool; both are trivial to forge. Adler-32 is a poorer error detector than CRC-32 for short data, and Fletcher checksums do not detect some patterns of swapped blocks. The page calculates only the checksums listed and does not handle file format wrappers such as a complete zlib stream.

Choosing between the checksums

Pick Adler-32 when a format demands it, as zlib does, and when the data is long enough for the sums to spread, from a few hundred bytes upward. Pick a Fletcher variant when a protocol or datasheet names it, often in embedded firmware where the cost of a division matters. For anything else, a CRC detects more kinds of damage at similar cost, and a cryptographic hash is the only choice when someone might alter the data on purpose.

Related tools

• CRC Calculator handles stronger checks including CRC-32.
• Hash Generator gives cryptographic digests.
• XOR Calculator shows the simplest checksum idea, an XOR of bytes.
• Base64 Encoder converts binary test data to text and back.