Hex LRC Calculator
Compute the LRC (Longitudinal Redundancy Check) of a hex byte sequence — the two's-complement checksum used by Modbus ASCII and Intel HEX.
Built by
Swapnil SanghviFull-Stack Web Developer & WordPress Developer
Swapnil Sanghvi is a full-stack web and WordPress developer, UI designer, and full-time freelancer who builds and maintains Hex Calculator.
Further reading: Cyclic redundancy check — Wikipedia
How LRC Is Calculated
Add every byte in the message together, keep only the low 8 bits, then take the two's complement of that sum (invert every bit and add 1). The result is the LRC byte, appended to the end of the message.
LRC Example, Step by Step
01 03 00 -> LRC FC
LRC(0x01, 0x03, 0x00) = 0xFC
0x01 + 0x03 + 0x00 = 0x04 (sum) Two's complement of 0x04 = 0xFC
| Step | Description | Result |
|---|---|---|
| Sum the bytes | 0x01 + 0x03 + 0x00 = 0x04 | 0x04 |
| Take the two's complement | invert the bits and add 1 | 0xFC |
Checking this: 0x01 + 0x03 + 0x00 + 0xFC = 0x100, which mod 256 is 0x00 — exactly the self-checking property LRC is designed around.
Where LRC Actually Comes Up
Verifying a Modbus ASCII Frame
Modbus ASCII mode appends an LRC byte to every frame — a receiver sums the frame bytes plus the LRC and confirms the mod-256 total is 0x00 to detect a corrupted message.
frame bytes + LRC sums to 0x00
Checking an Intel HEX Record
Every line of an Intel HEX file ends in a checksum byte computed the same way as LRC — programming tools recompute it to catch a corrupted or mistyped record before flashing firmware.
:10 0000 00 ... checksum
Debugging a Serial Protocol That Documents LRC
When a device's protocol spec calls for an LRC field, computing it here confirms what value a given message should carry before troubleshooting further.
match a datasheet's documented LRC value
Why Use This Calculator Instead of Doing It by Hand
- Shows the intermediate sum alongside the final two's-complement LRC value
- Accepts space-separated byte lists, matching how hex dumps are usually written
- Runs entirely in your browser — nothing you type gets sent anywhere
- Saves manual two's-complement arithmetic on longer messages
Limitations
- This is an 8-bit additive checksum with a two's-complement finishing step — it won't catch every corruption pattern (like two bytes swapping) the way a CRC would.
- Some protocols compute LRC over only part of the frame (excluding start/end markers) — check your specific protocol's spec for exactly which bytes to include.
Frequently Asked Questions
What is LRC, exactly?
Longitudinal Redundancy Check — sum every byte in the message, keep the low 8 bits, then take the two's complement (invert the bits and add 1) of that sum. It's an additive checksum with one extra step.
Why take the two's complement instead of just using the sum?
Because it makes verification self-checking — adding all the message bytes plus the trailing LRC byte together always sums to exactly 0x00 (mod 256) if nothing was corrupted, which is a convenient property for a receiver to check.
Where is LRC actually used?
Modbus ASCII mode appends an LRC to every message frame, and the Intel HEX file format uses the same two's-complement technique for its per-line checksum byte.
Is LRC the same as a CRC?
No — despite the similar-sounding name, LRC is a simple additive checksum (with a two's-complement twist), while CRC uses polynomial division and catches a wider range of corruption patterns.