Fletcher Checksum Calculator

Calculate the Fletcher-16 and Fletcher-32 checksums of any text or hex input. Both algorithms maintain two running sums that make the result sensitive to byte order, catching errors a plain additive checksum misses. The component sums and the combined value are shown in hex and decimal, computed live in your browser.

How to use the Fletcher Checksum Calculator

Type or paste into the input and pick Text or Hex bytes. In hex mode bytes may be separated by spaces or commas with an optional 0x prefix; in text mode the input is converted to UTF-8 bytes first. The two cards update live, one for Fletcher-16 and one for Fletcher-32, each showing the combined checksum in hexadecimal and decimal along with its two internal sums.

The default input abcde matches the widely published test vectors, so you can confirm the values: Fletcher-16 gives 0xC8F0 and Fletcher-32 gives 0xF04FC729. Fletcher-16 processes the data one byte at a time, while Fletcher-32 processes it two bytes at a time as 16-bit words; when the byte count is odd, the final word is padded with a zero byte, which is the standard convention.

Everything is computed in your browser, so the checksums are instant, work offline, and nothing you enter is uploaded anywhere.

How Fletcher beats a plain sum

The Fletcher checksum, devised by John G. Fletcher at Lawrence Livermore in the late 1970s, is a position-sensitive checksum that is nearly as cheap to compute as adding up all the bytes, yet catches far more errors. A naive checksum — just summing the bytes — has a glaring weakness: it does not depend on order, so swapping two bytes, or any rearrangement, leaves the sum unchanged and the error undetected. It also misses many cases where one byte goes up and another goes down by the same amount. Fletcher fixes this by maintaining two running sums instead of one.

The first sum, sum1, is the ordinary running total of the data values, each addition taken modulo 255 (for Fletcher-16) or 65535 (for Fletcher-32). The second sum, sum2, adds in the current value of sum1 after each step. That small twist is what makes the result depend on position: a byte early in the message gets folded into sum2 many times, while a byte near the end is added only once, so moving a byte changes sum2 even when sum1 is identical. The final checksum concatenates the two sums — sum2 in the high half and sum1 in the low half — giving a 16-bit value for Fletcher-16 and a 32-bit value for Fletcher-32. The choice of modulus is deliberate: using 255 and 65535 (one less than a power of two) rather than 256 and 65536 improves the error-detection properties and is the detail that distinguishes a correct implementation.

Compared with a cyclic redundancy check of the same width, Fletcher is weaker at catching certain burst errors but considerably cheaper, since it needs only additions and a periodic modulo rather than the bit-by-bit polynomial division a CRC performs. That trade-off made it popular in places where speed matters and the data is already fairly trustworthy: it is used in the TCP/IP-adjacent world, most notably as the checksum in the OSI/ISO transport protocols and in routing protocols such as IS-IS and OSPF. The closely related Adler-32, used in zlib, is a variant of the same idea with a prime modulus. Understanding Fletcher is therefore a useful lens on the whole family of additive checksums: two accumulators, a carefully chosen modulus, and a concatenated result give you order-sensitivity almost for free.

Common use cases

  • Protocol checksums. Compute the Fletcher value used in IS-IS, OSPF, or OSI transport packets.
  • Data integrity. Add a cheap, order-sensitive checksum to a record or message.
  • Verifying implementations. Check your code against the published abcde test vectors.
  • Learning checksums. See how the two running sums make the result depend on byte order.

Frequently asked questions

Why does Fletcher use two sums?
The second sum accumulates the first after every byte, so each byte's contribution depends on its position. This makes the checksum sensitive to byte order, catching transpositions that a plain additive sum would miss.

Why modulo 255 and 65535 instead of 256 and 65536?
Using one less than a power of two improves error detection and is part of the standard definition. Implementations that use 256 or 65536 produce different, weaker results that will not match published vectors.

How is Fletcher-32 different from Fletcher-16?
Fletcher-32 processes the data as 16-bit words (two bytes at a time) with modulus 65535 and yields a 32-bit result, while Fletcher-16 processes single bytes with modulus 255 and yields 16 bits. An odd final byte is padded with zero.

How does Fletcher compare to a CRC or Adler-32?
It is cheaper than a CRC but slightly weaker on burst errors. Adler-32 is a close relative that uses a prime modulus and is used in zlib. All three trade speed against detection strength.