Checksum calculator for byte strings
Compute every common non-cryptographic checksum over the same input at once: 8/16/32-bit sums, one’s- and two’s-complement, XOR (LRC), Fletcher-16/32, Adler-32, and the Internet checksum (RFC 1071). Feed it text, hex, or binary, toggle endianness for the word sums, and read the result in hex, decimal, or binary.
How to use this tool
What it does
Computes common checksums over input bytes for quick integrity comparison.
When to use it
Use it to confirm a payload matches an expected value or to reproduce a checksum a device reports.
Worked example
Paste a record and compare its checksum against the value printed by your reader.
Input
Result
What this tool does
A checksum condenses a block of bytes into a short fixed-width value so a reader can tell whether the block arrived intact. This calculator runs ten of the most widely used non-cryptographic checksums over the same input and shows every result side by side, which is exactly what you want when you are reverse-engineering an undocumented frame format and do not yet know which algorithm a device uses. Paste the payload, then scan the column for the value that matches the trailer byte already in the message.
The families covered are: plain additive sums truncated to 8, 16, or 32 bits; the one’s-complement and two’s-complement variants of the 8-bit sum; the XOR checksum (the same longitudinal redundancy check, or LRC, used in many serial and smart-card protocols); the position-sensitive Fletcher-16 and Fletcher-32; Adler-32 as used by zlib; and the 16-bit one’s-complement Internet checksum specified in RFC 1071 and carried in IP, TCP, UDP, and ICMP headers.
When to use it
Reach for this tool when you are validating or forging a trailer on a protocol frame, debugging a firmware update that a bootloader rejects with a “bad checksum” error, or confirming that a zlib/PNG stream’s Adler-32 matches. It is also handy for teaching: changing one byte of the input and watching which checksums move (and which collide) makes the error-detection trade-offs concrete. For polynomial CRCs see the dedicated CRC and LRC utilities in the resource library; for the byte-level views you will pair this with, see the encoding tools below.
Input and output
The Input is selector controls how your text is turned into bytes. Text (UTF-8) encodes the characters as UTF-8. Hex bytes accepts pairs of hex digits with optional spaces, commas, colons, or 0x prefixes. Binary bits accepts a run of 0/1 whose length is a multiple of eight. The Word order toggle only affects the 16-bit and 32-bit additive sums, because those are the only algorithms here that group bytes into multi-byte words before adding; all the others are defined byte-by-byte or on a fixed order. The Show as selector renders each result in hex (zero-padded to the algorithm’s width), decimal, or grouped binary. The Copy button exports every row as tab-separated label value lines.
Common mistakes
- Treating a checksum as security. Sum, XOR, Fletcher, Adler-32, and the Internet checksum all detect accidental corruption only; an attacker can trivially adjust bytes to hit any target. Use a hash or a keyed MAC for tamper resistance.
- Wrong endianness on word sums. A 16-bit or 32-bit sum that is “almost right” is usually a little-endian/big-endian mix-up — flip the toggle before assuming the spec is wrong.
- Forgetting the seed. Adler-32 starts from
1(not0) and Fletcher accumulators start from0; an implementation that seeds them differently will never match. - Including or excluding the wrong bytes. Many protocols checksum only part of a frame (often skipping the checksum field itself). Trim your input to the exact covered range.
- Odd-length input for 16-bit algorithms. The Internet and 16-bit sums conventionally pad a trailing odd byte with a zero; this tool does that, but a peer that pads differently will disagree.
Related tools
Frequently asked questions
Which checksum should I use to detect errors?
It depends on the threat. A plain 8-bit additive sum or XOR (LRC) catches single-bit and most burst errors and is trivial to compute on tiny micro-controllers, but it misses reordering and pairs of cancelling errors. Fletcher-16/32 and Adler-32 add a positional component so byte transpositions are detected, at very low cost. For Internet protocols the RFC 1071 16-bit one's-complement checksum is standard. None of these are cryptographic — for tamper resistance use a hash or a keyed MAC, not a checksum.
What is the difference between a one's-complement and two's-complement checksum?
Both are derived from the simple byte sum. The one's-complement checksum is the bitwise NOT of the truncated sum, so the sum plus the checksum equals all-ones. The two's-complement checksum is the arithmetic negation of the sum, so the sum plus the checksum wraps to zero — appending it makes the total of all bytes equal zero, which is convenient for verification. This tool reports both over an 8-bit accumulator.
Why does endianness matter for the 16-bit and 32-bit sums?
When bytes are grouped into 16-bit or 32-bit words before adding, the byte order inside each word changes the numeric value of every word and therefore the sum. Little-endian and big-endian grouping give different results for the same bytes. The 8-bit sum, XOR, Fletcher, Adler-32, and the Internet checksum are defined byte-by-byte or on a fixed word order, so the endian toggle does not change them; it only affects the 16-bit and 32-bit additive sums.
Are these checksums safe against deliberate tampering?
No. Sum, XOR, Fletcher, Adler-32, and the Internet checksum are integrity checks for accidental corruption only. An attacker can append or adjust bytes to force any target value, so they provide no authentication. For tamper detection use a cryptographic hash such as SHA-256, and for authenticity use a keyed MAC such as HMAC or CMAC verified by a secure element.
Does any of my data leave the browser?
No. Every checksum on this page is computed locally in JavaScript. Nothing you type or paste is uploaded, logged, or sent to a server, so it is safe to checksum sensitive payloads, firmware images, or APDU scripts.