A 16-bit checksum is a fixed two-byte value computed from a defined range of message bytes using a published formula such as CRC-16-CCITT, CRC-16-MODBUS, or the Internet one's-complement sum, and the same input must always produce the same output under that formula. The number 16 in 16-bit refers only to the width of the result: every accepted byte set maps to exactly two bytes, commonly written as four hexadecimal digits. The algorithm itself varies by protocol, which is why a vendor document should always be read alongside any calculator. Width, initial value, byte range covered, polynomial, reflection, and final transformation all change the output. The Checksum Calculator implements two transparent 8-bit formulas and an additive sum modulo 256; it is useful for the byte-level checks used by serial and Modbus ASCII devices but is not the right tool when the protocol specifies CRC-16, Fletcher-16, the Internet checksum, or any named cryptographic hash. Knowing which formula your target protocol expects is the first decision; the second is matching the exact byte sequence to feed in.
What a 16-Bit Checksum Produces
Every protocol that calls its check a 16-bit checksum commits to two specific facts: the result is exactly two bytes wide, and the calculation is fully deterministic so the receiver can recompute it and compare. Everything else is open to interpretation. Different families of 16-bit checks rely on completely different math:
- CRC-16 families treat the input as a polynomial over GF(2) and divide it by a fixed generator polynomial, then publish the remainder. The polynomial, initial value, reflected-input flag, reflected-output flag, and final XOR all change the answer.
- The Internet checksum used in IPv4, TCP, and UDP treats the data as 16-bit words, sums them using one's-complement arithmetic, and folds the carry back into the low 16 bits.
- Fletcher-16 keeps two running sums (a simple sum and a modular sum of that sum) and outputs both as two bytes.
- Adler-16 is the same family with different moduli and is rare outside niche applications.
A single byte of difference in the input is enough to change all two bytes of the output for any of these formulas, and any 16-bit checksum can be defeated by an attacker who can edit the message: there are only 65,536 possible outputs and billions of single-byte edits. The width protects against random corruption, not against tampering.
Common 16-Bit Checksum Formulas You Will Meet
Three families cover most embedded, industrial, and networking uses.
CRC-16
CRC-16 is the most widely deployed 16-bit check. Common parameter sets include CRC-16-CCITT (polynomial 0x1021, initial 0xFFFF or 0x0000), CRC-16-MODBUS (polynomial 0x8005, initial 0xFFFF, reflected input and output), CRC-16-IBM, CRC-16-USB, and CRC-16-XMODEM. Each variant returns a distinct 16-bit value for the same input. The BALTECH XOR-8 BCC reference shows how vendor documentation can vary even for a simpler one-byte formula, which is why CRC-16 implementations must quote every parameter from the protocol.
Internet checksum (RFC 1071)
Used in IPv4, ICMPv4, TCP, and UDP. The data is grouped into 16-bit words, summed with end-around carry, and the 16-bit one's complement of the result is transmitted. The receiver computes the same sum over data plus the checksum field; a correct frame sums to all-ones (0xFFFF). For a deeper walkthrough of a related cyclic check, see the step-by-step CRC-32 integrity guide.
Fletcher-16
Two accumulators, sum1 and sum2, are updated modulo 255 and modulo 255 over sum1 respectively. The output is (sum2 << 8) or sum1. Common in zlib-style applications alongside Adler-32.
None of these are produced by the Checksum Calculator. It deliberately stops at 8-bit formulas so that its output is unambiguous, and so the result a reader pastes into a forum or ticket matches a labeled formula rather than an unknown mix.
Calculate the 8-Bit Variants with the Checksum Calculator
For protocols that use a one-byte check, the Checksum Calculator shows three explicit values over the same byte set. Use it when the spec calls for XOR-8 BCC, Modbus ASCII LRC, or an additive sum modulo 256.
- Pick the input mode that matches the protocol. UTF-8 text is the right choice when the payload is a printable string; hexadecimal bytes (two hex digits per byte, optional whitespace) is the right choice when the spec gives you raw bytes such as 01 03 00 00 00 06.
- Enter only the bytes covered by the check. The Modbus ASCII LRC explicitly excludes the starting colon and the ending CRLF; enter the message bytes between them, not the whole line. Other protocols may include or exclude length and address bytes; the spec is the authority.
- Run Calculate. The page displays three labeled values—XOR-8 BCC, Modbus ASCII LRC, and raw byte-sum modulo 256—each as exactly two lowercase hex digits, plus the exact number of bytes processed.
- Compare and copy. Match the labeled value against the device documentation. The copy output includes labels, all three values, and the byte count so a pasted diagnostic note preserves which formula was used.
Malformed hexadecimal input (odd nibbles, stray commas, mixed separators) is rejected rather than silently corrected, and inputs above 500,000 bytes are refused without truncation. If you need CRC-16, the Internet checksum, or a named hash, this tool is not the right place—use a CRC or hash tool that quotes its parameters.
Worked Example: A Modbus-Style Frame
To make the formulas concrete, take six bytes that resemble a Modbus read request header: 01 03 00 00 00 06. Below is the exact arithmetic for each of the three values the calculator reports over those bytes.
XOR-8 BCC starts at zero and XORs every byte in turn:
- 0x00 XOR 0x01 = 0x01
- 0x01 XOR 0x03 = 0x02
- 0x02 XOR 0x00 = 0x02
- 0x02 XOR 0x00 = 0x02
- 0x02 XOR 0x00 = 0x02
- 0x02 XOR 0x06 = 0x04
Result: BCC = 0x04. Carries do not matter in XOR, and order is irrelevant.
Byte sum modulo 256 adds the six bytes and keeps the low eight bits:
- 0x01 + 0x03 + 0x00 + 0x00 + 0x00 + 0x06 = 0x0A (10 in decimal)
Result: Sum = 0x0A.
Modbus ASCII LRC takes the two's complement of that sum, which is the same as the negative byte sum modulo 256:
- −0x0A mod 256 = 0xF6 (256 minus 10 equals 246)
Result: LRC = 0xF6. As a quick sanity check, sum + LRC modulo 256 is 0x0A + 0xF6 = 0x100, which discards the carry and leaves 0x00. The receiver sees the same zero, which is how Modbus ASCII validates the message.
Comparing 16-Bit and 8-Bit Checks Side by Side
| Property | Typical 16-bit check (CRC-16 / Internet) | 8-bit check (XOR-8 BCC / Modbus LRC) |
|---|---|---|
| Result width | Two bytes, four hex digits | One byte, two hex digits |
| Detects all single-bit errors | Yes for CRC-16 with appropriate polynomial; yes for Internet checksum in normal framing | Yes for XOR-8 and additive LRC |
| Detects most burst errors | CRC-16 catches bursts up to 16 bits; Internet checksum is weaker on long bursts | Short bursts only; an even number of identical flips cancels in XOR or additive forms |
| Math | Polynomial division or one's-complement word sum | Single-byte XOR or single-byte add then two's complement |
| Parameter sensitivity | High: polynomial, initial value, reflection, and final XOR all change the output | Lower: mostly initial value (0 for XOR-8, 0 for additive) and whether framing is included |
| Authentication | None; any 16-bit value is forgeable | None; only 256 possible outputs |
| Typical protocols | Modbus RTU, IPv4, TCP, UDP, USB, Bluetooth HCI | Modbus ASCII, certain serial frames, simple device protocols |
Width is only one factor. A well-chosen 16-bit CRC can catch every single-bit error and most multi-bit errors in a long frame, while an 8-bit XOR or additive check has fewer possible outputs and a higher chance of a collision on the same payload.
When a Checksum Is the Wrong Tool
Every formula in this article is an error-detection check, not an authentication or encryption primitive. Two messages with the same 8-bit checksum are easy to construct deliberately, and a CRC-16 collision is only marginally harder. For credential transport, command authorization, software download verification, or any traffic that may face an active adversary, the protocol must specify a cryptographic MAC such as HMAC-SHA-256 or a digital signature. A checksum that simply confirms a message arrived intact is not a security boundary.
If a target spec names CRC-16, Fletcher, Adler, the Internet checksum, or any cryptographic hash, pick a tool that quotes the exact parameters it implements. The Checksum Calculator is intentionally narrow: it reproduces two named 8-bit formulas and an additive sum, so the labels match the device documentation rather than guess at intent.
If you're weighing options, How to Calculate a CRC Checksum Step by Step covers this in detail.