The XOR-8 block check character (BCC) is the running XOR of every byte in a selected range, kept in a single eight-bit accumulator that starts at 0x00 and never produces carries. Because XOR is commutative, the order of the bytes does not matter; the result depends only on the multiset of bytes covered. That single-byte result is what most device manuals label "BCC," though the same label is sometimes used for an additive checksum, an LRC, a CRC, or a checksum over a different part of the frame. To make the choice explicit, a cheat sheet has to spell out the formula, the included bytes, the width, and any final transform. The XOR-8 BCC, the raw sum modulo 256, and the Modbus ASCII two's-complement LRC all share an eight-bit output but differ in their last step: XOR-8 leaves the accumulator alone, the raw sum truncates carries, and the Modbus LRC truncates carries and then takes the two's complement. Treating them as interchangeable values is the most common reason a "BCC" field is rejected by a device.
What the three 8-bit values actually are
A useful BCC checksum cheat sheet has to keep the three common eight-bit formulas clearly separated, because each one answers a slightly different question about the same byte sequence. The XOR-8 BCC asks "what single byte captures the parity pattern of the input?" The sum modulo 256 asks "what is the low byte of the ordinary arithmetic sum?" The Modbus ASCII LRC asks "what single byte, when appended to the input, makes the low byte of the sum equal to zero?" Each row in the table below describes one of those formulas without leaving any step implicit.
| Property | XOR-8 BCC | Sum modulo 256 | Modbus ASCII LRC |
|---|---|---|---|
| Initial value | 0x00 | 0x00 | 0x00 |
| Operation per byte | XOR into accumulator | add into accumulator | add into accumulator |
| Carry behavior | carries do not occur | discard carries past bit 7 | discard carries past bit 7 |
| Final transform | none | none | two's complement |
| Result width | 8 bits | 8 bits | 8 bits |
| Output format | two lowercase hex digits | two lowercase hex digits | two lowercase hex digits |
The Modbus ASCII LRC is the negative of the sum modulo 256, so the sum and the LRC always add to zero modulo 256. Showing both side by side is a deliberate diagnostic choice: if a vendor document says "checksum equals the sum of bytes," the sum modulo 256 column is the answer; if it says "LRC" or "longitudinal redundancy check," the LRC column is the answer; if it says "BCC" with no further clarification, you have to check whether the manual describes XOR or addition before deciding which column to trust.
How to compute a BCC checksum step by step
The fastest way to verify a manual's "BCC" example against your own code is to compute the same value locally with an explicit formula. The Checksum Calculator reproduces the three formulas in this cheat sheet and reports the byte count it actually processed, which lets you confirm whether you entered the right byte range rather than guessing.
- Pick the input representation. Use the hexadecimal bytes mode when the manual lists the message as a sequence of two-digit hex values such as 01 03 00 00 00 0A. Use the UTF-8 text mode when the manual shows the message as a printable ASCII string. Browsers always encode text as UTF-8 first, so a single non-ASCII character can contribute several bytes to the count.
- Enter exactly the bytes covered by the checksum. If the protocol excludes the starting colon or the trailing CRLF, type only the payload bytes. The calculator will not strip framing for you; it treats whatever you type as the byte range it has to process.
- Run the calculation. The page displays the byte count it processed alongside three labeled two-character hex results: the XOR-8 BCC, the sum modulo 256, and the Modbus ASCII LRC.
- Compare the result to the manual's worked example. If the manual says "BCC" and gives a worked example, recompute the same example locally before trusting any other answer. If a vendor describes BCC as additive rather than XOR-based, the sum modulo 256 column is the value to compare.
- Copy the labeled block. The copy output keeps every label, all three values, and the byte count, so a pasted note still documents which interpretation was used.
What bytes to include and exclude
The single largest source of mismatched checksums is a wrong byte boundary. Different manuals draw that line in different places. The Modbus over Serial Line specification excludes the ASCII starting colon (:) and the trailing CR LF from the bytes supplied to the LRC; only the address, function, and data fields themselves are summed. BALTECH's reference for the eight-bit BCC XOR defines the same XOR-from-zero behavior over selected bytes; the exact byte range depends on the specific protocol or device. Other vendors include a leading length byte, or sum from a header field to a terminator, or define a separate "check code" that covers everything between two markers. Before using any cheat sheet value, find the exact byte range in the protocol document and re-enter only those bytes.
In hexadecimal mode, the calculator rejects prefixes such as 0x, commas, colons, and dashes, and it rejects any byte that is not exactly two hex digits. That strict parsing prevents silent guesses when a pasted frame is malformed. In text mode, the calculator reports the number of UTF-8 bytes it processed, which can exceed the visible character count when the message contains accented letters or CJK characters. Inputs above the page's 500,000-byte ceiling are not silently truncated; the calculator reports the malformed input rather than producing a partial value.
Worked example: XOR-8 BCC for 01 02 03 04
To see the formula in motion, take four bytes: 0x01, 0x02, 0x03, and 0x04. The XOR-8 BCC starts at 0x00 and folds each byte into the accumulator one step at a time:
0x00 XOR 0x01 = 0x010x01 XOR 0x02 = 0x030x03 XOR 0x03 = 0x000x00 XOR 0x04 = 0x04
The XOR-8 BCC is therefore 0x04. The sum modulo 256 over the same four bytes is 0x01 + 0x02 + 0x03 + 0x04 = 0x0A. The Modbus ASCII LRC, the two's complement of 0x0A, is 0xF6. As a quick cross-check, 0x0A + 0xF6 = 0x100, whose low byte is 0x00, confirming that the sum and the LRC add to zero modulo 256. For any other payload, run the same three lines against the Checksum Calculator and verify each result against the manual before sending it on the wire. The XOR-8 result can also be confirmed against BALTECH's eight-bit BCC reference, which defines the same XOR-from-zero behavior over the selected payload.
When a BCC cheat sheet is the wrong tool
An eight-bit BCC detects some accidental changes but has too many collisions to be useful for anything more serious. If the protocol calls for a CRC-16, CRC-32, Fletcher-16, Fletcher-32, Adler-32, the Internet checksum, or any named cryptographic hash such as MD5, SHA-1, or SHA-256, none of the three formulas in this cheat sheet will match. A one-byte XOR can be deliberately adjusted to any chosen value by flipping one matching byte, and the same is true of an additive LRC, so these values must never be used to authorize commands, protect credentials, verify software downloads, or authenticate untrusted network traffic. Use the security mechanism the protocol actually specifies, which is usually a MAC or a digital signature rather than a checksum.
For a complementary look at the same byte-level error detection from a different angle, the BCC checksum API alternative guide walks through how a local calculator avoids the round-trip latency and data exposure of a hosted API. When the manual names a wider checksum such as a 16-bit XOR pair or the more common 32-bit CRC, the worked formula changes and a dedicated tool is the safer choice; the CRC32 Calculator covers the most common wider alternative.
If you're weighing options, Base58 Decode Explained: How Raw Bytes Are Recovered covers this in detail.