CRC CalculatorChecksum Calculator
Type text, paste hex bytes or pick a file to see every common checksum at once — simple sums and XOR, Fletcher and Adler, CRC-8 to CRC-64, and the MD5 and SHA hashes. Use it to find out which checksum a device or file format is using.
Text is encoded as UTF-8.
Checksums hexadecimal
Simple checksums
- Sum-8sum of bytes mod 256
- dd
- LRC (two's complement)Modbus ASCII, Intel HEX
- 23
- XOR-8 (BCC)NMEA 0183, serial protocols
- 31
- Sum-16sum of bytes mod 65536
- 01dd
- Sum-32sum of bytes mod 2^32
- 000001dd
- Internet checksumRFC 1071 — IPv4, TCP, UDP, ICMP
- f62a
- Fletcher-16position-sensitive sum
- 1ede
- Adler-32zlib streams
- 091e01de
CRC
- CRC-8SMBus, sensors
- f4
- CRC-16CRC-16/ARC (IBM)
- bb3d
- CRC-16/CCITTCCITT-FALSE variant
- 29b1
- CRC-16/MODBUSModbus RTU
- 4b37
- CRC-32ZIP, gzip, PNG, Ethernet
- cbf43926
- CRC-32CiSCSI, ext4, cloud storage
- e3069283
- CRC-64CRC-64/XZ
- 995dc9bbdf1939fa
Cryptographic hashes
- MD5legacy, not collision-resistant
- 25f9e794323b453885f5181f1b624d0b
- SHA-1legacy, Git object IDs
- f7c3bc1d808e04732adf679965ccc34ca7ae3441
- SHA-256current standard
- 15e2b0d3c33891ebb0f1ef609ec419420c20e320ce94c65fbc8c3312448eb225
What a checksum is for
Data gets damaged: a bit flips on a serial line, a download is cut short, a flash cell wears out. A checksum is the cheapest way to notice. The sender computes a short value from the data and attaches it; the receiver computes it again and compares. A mismatch means the data cannot be trusted. A match means it is very probably intact — how probably depends on the algorithm.
The algorithms differ in how many errors they catch, how long the result is, and whether they hold up against someone changing the data deliberately.
Checksum algorithms compared
| Algorithm | Size | Catches | Misses | Typical use |
|---|---|---|---|---|
| Sum-8 / LRC | 8 bits | Any single-bit error | Swapped bytes, errors that cancel out | Intel HEX, Modbus ASCII, simple serial frames |
| XOR-8 (BCC) | 8 bits | Any single-bit error | Swapped bytes, two errors in the same bit column | NMEA 0183 GPS sentences |
| Internet checksum | 16 bits | Most random errors | Swapped 16-bit words | IPv4, TCP, UDP headers |
| Fletcher-16 | 16 bits | Reordered bytes too | Cannot tell 0x00 from 0xFF | Embedded protocols, OSI transport |
| Adler-32 | 32 bits | Reordered bytes | Weak on inputs shorter than a few hundred bytes | zlib |
| CRC-16 | 16 bits | All bursts up to 16 bits | 1 in 65,536 of other errors | Modbus, USB, XMODEM |
| CRC-32 | 32 bits | All bursts up to 32 bits | 1 in 4.3 billion of other errors | ZIP, PNG, Ethernet |
| MD5 | 128 bits | All accidental errors | Deliberate collisions | Legacy download checks |
| SHA-256 | 256 bits | Accidental and deliberate changes | — | Software releases, signatures |
Working out a simple checksum by hand
Take the four bytes 01 03 00 0A.
- Sum-8: 0x01 + 0x03 + 0x00 + 0x0A = 0x0E.
- LRC: the two's complement of that sum, 0x100 − 0x0E = 0xF2. Adding it to the data makes the total come out as zero, which is how the receiver checks it.
- XOR: 0x01 ^ 0x03 ^ 0x00 ^ 0x0A = 0x08.
Paste those bytes into the calculator in Hex mode to confirm. Sums and XOR are easy to compute but blind to reordering: 01 03 and 03 01 give the same result. That weakness is why most protocols moved to CRCs.
Finding out which checksum a device uses
- Capture a message together with its checksum bytes.
- Paste the message without the checksum into Hex mode.
- Look for the captured value in the results. With a 16-bit value, try both byte orders.
- No match? The checksum may cover fewer bytes than you think — drop the start-of-frame byte or the address and try again. If it looks like a CRC, the CRC32 calculator lists 100 CRC variants for the same input, and the CRC16 calculator and CRC8 calculator narrow it down by width.
Related tools
- File checksum calculator — streams files of any size and compares against an expected value, for verifying downloads.
- Modbus CRC calculator — builds and verifies complete Modbus RTU frames.
- What is CRC32? — how a CRC is computed, with a worked example.
Frequently asked questions
What is a checksum?
A checksum is a small value computed from a block of data and stored or sent along with it. Whoever receives the data repeats the computation; if the two values differ, the data was changed on the way. Checksums range from a one-byte sum to a 256-bit cryptographic hash.
How do I calculate a checksum by hand?
For the simplest kind, add all the bytes together and keep only the lowest eight bits. For the ASCII text "123456789" the byte values add up to 477, or 0x1DD, so the 8-bit checksum is 0xDD. Protocols that want the total to come out as zero send the two's complement instead: 0x100 − 0xDD = 0x23.
Which checksum should I use?
If you are implementing an existing protocol or file format, use exactly the one it specifies. For a new design: CRC-32 or CRC-32C to catch accidental corruption, CRC-64 for very large objects, and SHA-256 whenever someone might change the data on purpose.
What is the difference between a checksum, a CRC and a hash?
A checksum is the general term. A CRC is a particular kind of checksum based on polynomial division, much better than a plain sum at catching reordered and burst errors. A cryptographic hash such as SHA-256 is designed so that nobody can construct two inputs with the same value; it is slower and longer, and it is the only one of the three that protects against deliberate tampering.
Why do two tools give different checksums for the same text?
Either they use different algorithms under the same name ("CRC-16" covers dozens of variants), or they are not hashing the same bytes: a trailing newline, Windows versus Unix line endings, or a different text encoding all change the result. In Hex mode you control the exact bytes.
Can a checksum be wrong even though the data is fine?
Only if the checksum itself was damaged or was computed over a different range of bytes than you assumed — for example with or without a header. The algorithm is deterministic: the same bytes always give the same checksum.