A BCC (Block Check Character) checksum is the result of XOR-ing every byte of a message together into a single eight-bit value, producing exactly two lowercase hexadecimal digits between 0x00 and 0xFF. The accumulator starts at 0x00, and each input byte is folded in with the XOR operator: same bits cancel, different bits stay. Because XOR is commutative and self-inverting, the final value depends only on the parity of each bit across the selected byte set, and reordering the bytes leaves the result unchanged. The eight-bit width means every bit beyond the lowest eight is discarded, so the output can never exceed 0xFF regardless of input length. The result fits in one byte and is usually appended to the message so the receiver can recompute it and compare. This simple block check character is widely used in serial device communication because the math is fast and the code is tiny, but the same word BCC is also reused by vendors for additive checksums, LRCs, CRCs, and even checksums over unrelated parts of a frame, so the vendor document is the only place that defines which formula a given device expects.
The XOR-8 formula, written out
The formula for an XOR-8 BCC is short enough to write in one line:
BCC = b[0] ⊕ b[1] ⊕ b[2] ⊕ … ⊕ b[n-1]
where each b[i] is a byte in scope and ⊕ is the XOR operator. The accumulator starts at zero, any byte XOR-ed with itself returns zero, and the running result reflects only the unpaired bits across the whole block. Because carries do not exist in XOR, byte order does not matter, and a duplicate byte cancels out cleanly.
Take the five-byte sequence 01 A0 7C FF 02. Working one step at a time:
- Start: BCC = 00
- 00 ⊕ 01 = 01
- 01 ⊕ A0 = A1
- A1 ⊕ 7C = DD
- DD ⊕ FF = 22
- 22 ⊕ 02 = 20
The final BCC is 20. Run the same five bytes through the Checksum Calculator and the labeled XOR-8 result will read 20 as well, with the byte count reported as 5. The BALTECH XOR-8 BCC reference describes this exact eight-bit XOR definition across selected payload bytes, which is the behavior the calculator reproduces.
How to compute a BCC checksum with the Checksum Calculator
- Open the Checksum Calculator in your browser.
- Pick the input mode that matches the device's actual representation: UTF-8 text for a printable string, or hex bytes for a raw packet. Use hex whenever the specification quotes bytes explicitly.
- Enter only the bytes the specification tells you to cover. For a standard Modbus ASCII LRC this means excluding the starting colon and the trailing CR/LF. For a generic XOR-8 BCC, include exactly the bytes between the framing the vendor document names.
- In hex mode, write each byte as exactly two hex digits, with optional whitespace between bytes. Prefixes like 0x, commas, colons, dashes, odd nibbles, or comments are rejected rather than guessed.
- In text mode, leave the string as-is; the browser encodes it to UTF-8 first, so a non-ASCII character can contribute several bytes and the displayed byte count can exceed the visible character count.
- Run the calculation. The page returns three labeled values: XOR-8 BCC, Modbus ASCII LRC, and the raw byte sum modulo 256, each as exactly two lowercase hex digits with a leading zero, plus the byte count processed.
- Match the labeled result that the vendor documentation names. If the document calls the value a BCC and describes an XOR, take that line. If it calls the value an LRC over an ASCII frame, take the Modbus ASCII LRC line. If it asks for an additive sum without a complement, take the sum modulo 256 line.
- Copy the output. The copy action includes labels, all three values, and the byte count, so a pasted note keeps the interpretation visible to the next reader.
Where XOR-8 BCC and the Modbus ASCII LRC diverge
The terms BCC and LRC are not interchangeable. They describe two distinct one-byte formulas, and many devices will reject a frame if you hand them the wrong one. The table below shows the practical difference.
| Property | XOR-8 BCC | Modbus ASCII LRC |
|---|---|---|
| Combine operation | Bitwise XOR across all bytes | Addition across all bytes, then two's complement |
| Initial value | 0x00 | 0x00 |
| Carry handling | Carries are irrelevant (XOR has none) | Carries discarded, low 8 bits kept |
| Output | The accumulator itself | Two's complement of the sum, equivalent to the negative sum modulo 256 |
| Pairing identity | Byte XOR-ed with itself cancels to the previous running value | The LRC plus its message bytes sum to 0x00 modulo 256 |
| Framing convention | Whatever the vendor names | Exclude the starting colon and the trailing CR/LF |
| Authoritative source | Vendor manual naming the XOR | Modbus over Serial Line specification V1.02 |
The calculator returns both formulas over the same byte set, which makes the contrast obvious. If you change the input by a single byte, the XOR-8 BCC changes in one well-defined way and the Modbus LRC changes in a different one, and seeing both lines next to each other is often the fastest way to catch a mistake. The sum modulo 256 is the low eight bits of the ordinary byte sum before the Modbus two's-complement step, which is why the sum and the LRC always add to 00 modulo 256.
Input rules the calculator enforces
The page never silently truncates or repairs bad input. That makes its rules worth reading once before you paste a long frame.
- Maximum input is 500,000 bytes. Larger inputs are rejected without producing a partial value.
- Hex mode accepts only two-digit hex bytes with optional whitespace between them. Odd nibbles, commas, colons, dashes, and 0x prefixes are refused.
- Text mode encodes the string as UTF-8 before calculation. A character such as é contributes two bytes and a character such as 🚀 contributes four, so the displayed byte count can exceed the visible character count.
- Output is always exactly two lowercase hex digits, including a leading zero for values below 0x10.
The copy action preserves all of this: labels, three values, and the byte count travel together, so a pasted diagnostic note keeps the interpretation visible to the next reader.
Why an XOR-8 BCC is not enough for authentication
An XOR-8 BCC is an error-detection device, not an authentication device. It catches some accidental bit errors on noisy wires, the math is fast, and the code fits on a microcontroller, and that is the right scope of contribution. It does not do the following, and treating it as if it did would be a serious misuse:
- It is not a cryptographic hash. Two completely different messages can share the same BCC by construction.
- It is not a message authentication code. Anyone who can transmit a frame can also transmit a frame with a valid BCC.
- It is not a digital signature. There is no key, no trust anchor, and no proof of origin.
- It is not encryption. The payload is in the clear.
- It does not authorize a command. A device that checks only a BCC has accepted the message on trust.
For credentials, software downloads, command authorization, or any untrusted network traffic, use the security mechanism the actual protocol requires. If the protocol names CRC-16, CRC-32, Fletcher, Adler, the Internet checksum, or a named cryptographic hash, this calculator is the wrong tool. Its value is transparent reproduction of two simple eight-bit formulas, not automatic protocol detection.
When you need a different algorithm
If the device documentation names anything other than an eight-bit XOR or an additive two's-complement LRC, the result the calculator returns is not the value you need. The table below names the most common alternatives and the tool path that handles them.
| Documented algorithm | Why XOR-8 BCC is not a substitute | Where to compute it |
|---|---|---|
| CRC-16 (Modbus RTU, USB, many others) | Polynomial division with a 16-bit state, not a single XOR byte | CRC-16 calculators that expose polynomial, initial value, reflection, and XOR-out parameters |
| CRC-32 (ZIP, Ethernet, PNG) | 32-bit state, fixed polynomial, reflected input and output | CRC32 Calculator for the standard ISO-HDLC variant |
| Fletcher-16 or Adler-32 | Two running accumulators, not a one-byte XOR | Specialized Fletcher and Adler tools |
| Internet checksum (RFC 1071) | 16-bit one's-complement sum over 16-bit words | Network protocol tools that preserve word order and endianness |
| SHA-256 or another cryptographic hash | Cryptographic strength is the requirement | SHA256 Hash Generator for a real digest |
The pattern across every row is the same: identify the exact algorithm, width, initial value, included fields, complement, and byte order the vendor document names, then compute the formula that matches. For a deeper worked walkthrough of the XOR-8 path itself, see the BCC checksum step-by-step example. For Modbus framing in particular, the official Modbus over Serial Line specification V1.02 is the reference that defines the LRC exactly.
If you're weighing options, How to Calculate a BCC Checksum for Beginners covers this in detail.