What is the difference between XOR-8 BCC and Modbus ASCII LRC?

XOR-8 BCC is the running XOR of every payload byte, while Modbus ASCII LRC is the two's complement (modulo 256) of the sum of those bytes. They produce different numbers from the same input.

Should I type my payload as text or hex?

Use the mode that matches your protocol's representation. If the spec writes the payload as ASCII characters, use UTF-8 text mode; if it writes raw byte values, use hexadecimal bytes mode.

Do I include start, end, and carriage-return characters in the checksum?

No, unless the protocol specification explicitly says to. Modbus ASCII in particular excludes the trailing CR and LF. Always read the spec's pseudocode to confirm which bytes are inside the checksum range.

Why does the tool show three different results for one input?

Because three different algorithms are being applied. The labels tell you which is which. Match the label to the formula named in your device documentation and copy that specific result.

Can a checksum detect every transmission error?

No. Checksums like XOR-8 and Modbus LRC catch many single-bit and burst errors but can be fooled by specific multi-byte patterns. For cryptographic-level integrity you need a hash such as SHA-256 or an HMAC.

How to Calculate Checksum: XOR-8 and Modbus LRC

A checksum is a fixed-size numeric value that a receiving device recomputes from incoming bytes and compares against a transmitted checksum to catch corrupted data. To calculate a checksum for a serial protocol such as Modbus ASCII or a simple framed packet that uses XOR-8, type the exact payload bytes into a tool that applies the documented formula byte by byte. The Checksum Calculator does exactly this: it returns the explicit XOR-8 BCC, the Modbus ASCII two's-complement LRC, and a plain byte-sum modulo 256, so you can match the algorithm to the one called out in your device's manual and copy the labeled result.

Serial protocols from simple microcontroller UARTs to industrial buses carry a few bytes at the end of every frame that let the receiver verify the rest of the message was not garbled by noise. Those bytes are not cryptographic hashes — they are cheap sums or XORs that catch flipped bits and truncated frames. The challenge for engineers and hobbyists is that different families of devices expect different formulas: some want XOR-8, some want Modbus ASCII LRC, and some document a raw byte sum reduced modulo 256. The right answer depends on what the spec actually says, not on what a search engine summarized.

The Three Checksums the Tool Computes

The Checksum Calculator exposes three explicit, well-defined algorithms so you can pick the one your hardware expects without guessing.

Algorithm	Formula in plain words	Typical use
XOR-8 BCC (Block Check Character)	Start with 0x00, XOR every payload byte in order, keep only the low 8 bits.	Serial framing on many microcontrollers, Modbus RTU trailers, generic UART protocols.
Modbus ASCII LRC	Sum the bytes, keep the low 8 bits, then take the two's complement (subtract from 0x100, drop overflow).	Modbus ASCII mode where the LRC is computed over the ASCII-hex payload before the CR LF is appended.
Byte-sum modulo 256	Add all bytes, keep only the low 8 bits of the total.	Custom industrial protocols, simple file integrity checks in legacy systems.

The Modbus LRC itself is documented on the Modbus Organization's specification page, and the XOR-8 BCC concept is the same basic integrity scheme used in many communication frameworks. Knowing which formula your protocol expects is half the work.

Choose the Right Input Format

Before you click anything, decide whether your protocol describes the payload as printable text (UTF-8) or as raw hexadecimal bytes. The tool offers both modes for exactly this reason.

UTF-8 text mode is what you want when the spec phrases the payload as ASCII characters, for example "01 03 00 00 00 0A" being the human-readable hex representation of the Modbus query bytes.
Hexadecimal bytes mode is what you want when the spec phrases the payload as a sequence of byte values, for example 01 03 00 00 00 0A, and lets the tool treat each pair of hex digits as a single byte.

Mixing the two is the most common mistake. If your device manual lists the payload as printable characters, the calculator needs those exact characters; if it lists raw bytes, you should paste the byte values directly. When in doubt, compare what your tools produce for a known frame against the worked example in the manual.

Calculate the Checksum Step by Step

Open the Checksum Calculator and pick the input mode that matches your protocol: UTF-8 text for printable payload strings or hexadecimal bytes for raw byte sequences.
Type or paste exactly the bytes covered by the checksum, in the same order they will be transmitted, omitting any framing characters that the specification says should be left out (for Modbus ASCII this means stop at the last data byte, before CR and LF).
Click Calculate. The tool returns the three labeled values side by side: the XOR-8 BCC, the Modbus ASCII LRC as a two-digit hex byte, and the byte-sum modulo 256.
Compare each returned value with the formula in the device documentation. Copy the specific result that matches the algorithm your protocol names — do not pick the largest or the smallest of the three.
Append the chosen value to the frame according to your protocol's rules: Modbus ASCII expects the two ASCII hex characters before CR LF; a simple XOR-8 protocol typically expects a single raw byte.
On the receiver, recompute the same checksum over the same byte range and confirm the new value matches the byte you sent. A mismatch means the frame is corrupted and should be discarded.

How the XOR-8 BCC Is Built Up

The XOR-8 BCC is the simplest of the three and worth working through once by hand. Suppose your payload bytes (in hex) are 01 03 00 00 00 0A. Start an accumulator at 0x00 and XOR each byte in turn, keeping the result 8 bits wide:

0x00 XOR 0x01 = 0x01
0x01 XOR 0x03 = 0x02
0x02 XOR 0x00 = 0x02
0x02 XOR 0x00 = 0x02
0x02 XOR 0x00 = 0x02
0x02 XOR 0x0A = 0x08

The XOR-8 BCC for that six-byte payload is 0x08. The same input fed to the byte-sum modifier 256 gives 0x0E (sum 0x10E, low byte 0x0E), while the Modbus LRC — the two's complement of that low byte — is 0xF2. If your spec asks for any of those three numbers, the corresponding field in the tool's output is the one you copy. Verify this kind of worked example once, and you will recognize immediately which output is wrong for a given protocol.

Why the Tool Labels Every Result Explicitly

It is not enough for a calculator to spit out "a checksum." The same input can legitimately yield three different bytes depending on which algorithm you meant. That is why the Checksum Calculator prints each result under a clear label: an XOR-8 BCC field, a Modbus ASCII LRC field, and a byte-sum modulo 256 field. The label is the contract between the tool's output and your protocol's documentation. Match the label to the formula in the manual before you transmit, and you eliminate the entire class of "wrong checksum" bugs that come from picking the right number with the wrong name.

Common Framing Mistakes That Change the Answer

Most checksum errors in serial work are not math errors — they are range errors. The checksum is computed over a precisely defined slice of the frame, and that slice is not always the entire visible message.

Including framing characters. A Modbus ASCII frame ends with a carriage return and line feed. Those two bytes are not part of the LRC calculation; including them produces a value that matches no real device.
Including the address byte in the wrong place. Some protocols checksum from the first byte after the start delimiter; others checksum from the address. Read the spec's pseudocode, not just the prose description.
Double-counting after escape characters. After a framing byte is escaped, the receiver must compute the checksum over the unescaped payload. If your payload contains the protocol's escape marker, make sure you hand the calculator the bytes after de-escaping, not the on-the-wire bytes.
Converting text to bytes incorrectly. If you paste 01030000000A as ASCII text, the tool sees fourteen characters' worth of bytes; if you paste the same string as hex pairs, it sees six. Always confirm the input mode and the byte count on a known-good reference frame first.

When a Checksum Is the Right Tool and When It Is Not

Checksums are intentional collision-likely: two different payloads can share the same XOR-8 value, and the receiver can detect single-bit errors but cannot recover the original data. That is exactly what you want for a noisy serial link where dropped or flipped bits are the main failure mode. It is not what you want when you need cryptographic integrity — for that, a hash such as SHA-256 or an HMAC is the appropriate primitive. For practical serial debugging, file integrity during transfer, or building a quick sanity check on a microcontroller payload, the three algorithms in the calculator cover the vast majority of protocols in the wild. If you are computing one of these values by hand for more than a few bytes, paste the payload into the tool and use its labeled results.

If your debugging also involves base-64 or hex-encoded data on the wire, it helps to keep related converters close at hand. The Base64 to Hex Converter decodes canonical Base64 strings into exact hexadecimal bytes, which is the format the Checksum Calculator expects when your device's payload rides inside a Base64 envelope. For protocols that serialize packets as ASCII hex strings, the Hex to Text Converter goes in the other direction so you can read a recorded frame without manual decoding. Both pair naturally with the checksum step, and like the calculator they run entirely in the browser.

More on this topic: How Do I Translate Morse Code | Tools and Methods.

For a deeper look, see How to Calculate CRC-32 Checksums for Data Integrity.