Checksum Calculator: Sum, XOR & Internet Ones-Complement

You might say, “I am sending this packet across the network” or “I am sending this firmware update across this microcontroller,” hoping it arrives. “I hope it gets there.” Optimistic! Bytes get corrupted by storage decay and interference and other forms of noisy disorder every day.

Checksums are little fingerprints computed from a block of bytes to let a recipient know if the data got through in one piece. Enter your hex/dec/plain-ASCII-text byte stream here. This calculator uses several classic checksumming algorithms on it, combining them into a single number. These include the one’s-complement Internet checksum, two’s-complement values used in firmware records, the XOR-based redundancy check, and even the simple-but-effective modular sum.

How Checksums Work

See the pass-or-fail verdict compared with your expected value, then the running total and how it gets wrapped into final result. The main task of each and every checksum are the same: to take lots of bytes and reduce them to some small number, which will change whenever the underlying data does. It’s easiest to just add up all those bytes. When there’s even a single flip in any of them, total is typically different then, and the recipient instantly sees the two aren’t matching.

They are designed to be inexpensive because they must operate on the tiniest microcontroller with the strictest power budget. They also run across every packet traversing a busy network backbone. They’re not cryptographic hashes, so they won’t prevent a malicious attack. But if you want to catch a dropped byte or other random transmission noise? A well chosen checksum does the job quick and effectively. This is a key factor when choosing what to use for an embedded system.

It calculates the running sum of all bytes, taking the low bits and discarding everything else. With SUM-8, this means the calculator do the addition and drops off the high byte. The result is one check byte (the remaining sum of all bytes modulo 256). With SUM-16, we take the sum modulo 65536. This means the result has twice as many bits but fewer overflows at the end of longer messages. Let’s look at the numbers 1, 9 in decimal, which are represented in ASCII. Their byte values range from 49 to 57. When added together, they make 477, while 477 modulo 256 equals 221 or 0xDD.

You can easily switch between moduli of 256 and 65536 using the width setting. Moreover, the breakdown panel displays the actual running sum as well, allowing you to track each step of calculation. That helps you trust the outcome.

Instead, the LRC (XOR) checksum takes the exclusive-OR of each byte. It’s like summing them except output bit is the parity of that bit at that position in all of the bytes. In other words, if there’s one or three or five flipped bits on that particular spot then the checksum will flip. GPS and most marine protocols use NMEA 0183 which uses XOR. All those hex digits following the asterisk are just the XOR of all characters in the sentence.

Its only quirk is that XOR doesn’t care about byte ordering. Changing two bytes doesn’t change result. So it’s easy but blind to byte transposition. For this reason, sums are often used with order dependent links. It does something but you need to understand what it doesn’t do.

Intel HEX files and Motorola S-records use a two’s-complement checksum. They do not record the actual sum, but the number whose addition would make total equal zero (sum modulo 256) again. That’s 256 minus the sum modulo 256. So if the sum of your data bytes is 150, then the checksum is 256. 150 = 106 or 0x6A. The beauty part is how it checks: add up all your data bytes and the checksum. The result will be exactly zero in its lower eight bits for a proper message. When we don’t expect a certain value, this calculator puts the surface check byte on the result card. What you see is always the balancing value of the frame.

This powers all the internet. It’s the most important algorithm of them all. The 16-bit one’s-complement checksum from RFC 1071 covers everything. This includes IPv4 headers, UDP datagrams, and TCP segments. Here’s how it works: Each 16-bit word of the data is treated as an unsigned integer, summed together. If the running sum ever goes over 0xFFFF, carry is end arounded back into the low 16 bits. Then, after folding-in all the words, the sum is bitwise inverted using a one’s complement. The receiver adds up all the words, including the checksum field, and should of get a result of 0xFFFF, aka all ones, which verifies there were no errors. This tool displays both the complement and the folded sum, and runs through carry-folding process.

So yeah, this feature lets you verify a checksum, which is cool. Fill out the expected field with whatever checksum a device said the data had. Select the right length and type, and the calculator checks whether the computed value match the pasted-in value. A green PASS means the bytes match the checksum. A FAIL means either the checksum algorithm was incorrect or at least one byte was different. It reinforces the two golden rules from the breakdown: append a sum-type checksum and the data will resume to 0. An Internet checksum should resum to 0xFFFF. These invariants allow you to verify a frame against itself, with no outside reference.

Which works best depends on your threat model. The weak-but-fast approach uses simple sums. It catches most single-bit noise but misses byte swaps. The Internet checksum adds with carry to get position-sensitivity. It is the right default for network work. If you really want robust error detection across bursts of errors, then a cyclic redundancy check like CRC-32 is much stronger. And it’s not in this live calculator.

Choose one of the presets, and tweak the number of bytes. Run the sum, and voila! One click and the correct checksum just falls out. You ship it off into the wild, hoping it gets there intact. The checksum is the silent proof it did.