LRC Calculator

What an LRC is for

A longitudinal redundancy check (LRC) is one of the oldest and simplest block-check values in data communications. You combine every byte of a message into a single one- or two-byte result, append it to the frame, and let the receiver recompute the same value. If the two disagree, the frame is corrupt and gets rejected or retransmitted. The name "longitudinal" comes from the original tape and teleprinter use: where a parity bit checks one character vertically, the LRC checks a whole column of characters lengthwise down the message.

The classic LRC is a byte-wise XOR of every covered byte — a longitudinal parity that flips with any single-bit change in a column. A second family is additive: sum the bytes and keep either the raw sum modulo 256 (or 65536), or its two’s-complement. The two’s-complement form is popular because adding it back into the running sum drives the total to zero, so a verifier just sums the data and the LRC and checks for a clean zero result.

When to use it

Reach for an LRC when a wire protocol explicitly specifies one. The XOR form appears in many proprietary serial links, point-of-sale terminals, and barcode framing. The two’s-complement additive form is the block check in ISO 8583-style financial messaging and in Modbus ASCII, where each frame ends with an LRC computed over the address, function, and data fields. If your protocol instead calls for polynomial integrity, you want a CRC, not an LRC — for example Modbus RTU uses a 16-bit CRC while Modbus ASCII uses this LRC. Use this tool to confirm a captured frame’s trailing byte, to generate the check value when hand-building a test frame, or to settle which bytes a vendor’s spec actually covers.

Input and output

Paste the message body as ASCII / UTF-8 text or as hex bytes (spaces, commas, colons and a leading 0x are ignored). Pick a variant, then toggle whether the leading STX (0x02) and trailing ETX (0x03) framing bytes are included in the computation — protocols differ, and this is the most common source of mismatches. The result panel shows the LRC in hexadecimal and decimal, the exact list of bytes that were processed, and a running-accumulator table listing each offset, byte value, printable character, and the accumulator after that step. For long inputs the table is capped to keep the page responsive; the final value is always exact.

Common mistakes

• Including or excluding the wrong framing bytes. Whether STX and ETX are inside the LRC varies by spec. Toggle them here to match your protocol exactly.
• Confusing modulo sum with two’s-complement. The modulo-256 sum and its two’s-complement differ by negation; picking the wrong one yields a value that looks plausible but never verifies.
• Treating hex input as text. The string 3132 is two bytes in hex mode but four characters in text mode. Set the input type before reading the result.
• Expecting CRC-grade detection. An LRC misses many multi-bit and transposition errors. For burst-error resilience use a CRC instead.
• Width confusion. An 8-bit LRC is one byte; the 16-bit variants emit two bytes. Send the bytes in the order your protocol expects.

Related tools