Hex Checksum Calculator
Compute a simple additive checksum over hex bytes, plus the two's-complement check byte used by Intel HEX files — both from the same input.
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 an Additive Checksum Works
Add every byte together, then keep only the low 8 bits of the total — that single byte is the checksum. It's fast and simple, but weaker than a CRC: swapping two bytes, for example, produces the same checksum even though the data changed, since addition doesn't care about byte order.
Checksum Example, Step by Step
12 34 56 -> checksum 9C, Intel HEX check byte 64
0x12 + 0x34 + 0x56 = 0x9C (checksum)
0x12 + 0x34 + 0x56 = 18 + 52 + 86 = 156 decimal = 0x9C Two's complement of 0x9C = 0x64
| Step | Description | Result |
|---|---|---|
| Add every byte | 0x12 + 0x34 + 0x56 = 156 decimal | 156 |
| Keep the low 8 bits | 156 already fits in a byte | 0x9C |
| Two's complement (Intel HEX style) | invert bits and add 1 | 0x64 |
An Intel HEX record would store 0x64 as its checksum byte — adding the data bytes plus that checksum byte together always sums to 0x00, which is how a reader verifies the line wasn't corrupted.
Where Hex Checksums Actually Come Up
Verifying an Intel HEX Record
Firmware programming tools compute the two's-complement checksum of each Intel HEX line and compare it to the trailing checksum byte to catch a corrupted or mistyped record before flashing it.
sum of line bytes + checksum byte = 0x00
Quick Sanity Check on Serial Data
Simple serial protocols often append a single additive checksum byte to a short message — fast to compute on constrained microcontrollers where a full CRC would be too slow.
message bytes + trailing checksum
Debugging a Firmware Update Payload
When a device rejects a firmware image, recomputing its expected checksum against the bytes you're sending is a quick first check before looking for deeper protocol issues.
payload bytes -> expected checksum
Why Use This Calculator Instead of Doing It by Hand
- Shows both the plain additive sum and the Intel HEX-style two's complement from one input
- Handles space-separated byte lists, matching how hex dumps are usually written
- Runs entirely in your browser — nothing you type gets sent anywhere
- Saves manually tracking the mod-256 wraparound for longer byte sequences
Limitations
- Implements the plain 8-bit additive sum and its two's complement — not every format's specific checksum rule (some use 16-bit sums, XOR-based checksums, or different wraparound behavior).
- This is weaker error detection than a CRC — it won't catch every corruption pattern (like two bytes swapping). Use the Hex CRC32 Calculator where stronger detection matters.
Frequently Asked Questions
How is a simple checksum calculated?
Add up every byte's value, then keep only the low 8 bits of the total (sum mod 256) — that single byte is the checksum.
What is an Intel HEX checksum, specifically?
Intel HEX is a file format used for programming microcontrollers and EPROMs, where each line ends in a checksum byte — the two's complement of the sum of all preceding bytes on that line, used to catch a corrupted or mistyped record. This calculator shows that value alongside the plain sum.
Why show both the sum and its two's complement?
"Checksum" means different things in different formats — some just want the additive sum, others (like Intel HEX) want the two's complement of that sum. Showing both from one input covers either meaning without needing a second calculator.
Is a checksum enough to guarantee data wasn't tampered with?
No — checksums catch accidental corruption (a flipped bit, a dropped byte), not intentional tampering. For security-relevant integrity checks, a cryptographic hash is the right tool instead.
Why does the checksum wrap around at 256?
Because it's stored in a single byte, which can only hold values 0-255 — once the running sum exceeds 255, only the low 8 bits are kept, which is standard behavior for an 8-bit additive checksum.