ByteScope

CRC Calculator

One input, 113 published CRCs, and a search that names the one your device is using.

Your bytes never leave your browser — every checksum is computed locally.

Input

9 bytesFirst bytes:31 32 33 34 35 36 37 38 39

Your own parameters

The six numbers of the Rocksoft model. A datasheet that describes a CRC describes exactly these, usually in this order, and often under no name at all.

Result

—

check over “123456789”

—

Every published CRC states this one value. If it equals the check in your datasheet, the six numbers above really are the algorithm that document means — before you trust the result on the left.

Every named CRC

One input, 113 published algorithms, all computed at once. Find the row whose result matches the checksum you are holding and you have found your algorithm.

0 algorithms

No algorithm matches that filter.

Work backwards from a checksum

You have a frame and the checksum it carries, and nobody wrote down which CRC produced it. Put the frame in the input above, the checksum here, and let the search answer it.

The value the device or the file actually carries for the bytes above.

Matches: 0

Past the 113 published models, the search tries every 8-bit and then every 16-bit polynomial, with init and xorout each all-zeroes or all-ones and both reflection settings. Widths above 16 are not brute-forced: four billion polynomials is not a search a browser tab finishes.

Non-CRC checksums

Not every trailing byte is a CRC. These eight are what the other half of the protocols in the world actually use, and they are computed over the same input.

ChecksumHexDecimal
sum8Bytes added up, kept to 8 bits.——
sum16Bytes added up, kept to 16 bits.——
xor8Every byte XORed together — the LRC of Modbus ASCII and of NMEA.——
fletcher16Two running sums mod 255, so reordering changes the answer.——
fletcher32The same idea over 16-bit little-endian words, mod 65535.——
adler32Fletcher's cousin, mod 65521 — the trailer on every zlib stream.——
internetChecksumRFC 1071: the one's complement of the one's complement sum of 16-bit big-endian words. IP, UDP and TCP headers.——
bsdChecksumRotate right, then add — what BSD sum(1) prints.——

NMEA 0183 sentence

Checksum—

XOR of every character between the leading $ or ! and the *. This one takes the sentence rather than the bytes above, because that is how the standard defines it.

About this tool

The two bytes at the end of the frame

A protocol dump ends in 4b 37 and the document you were given says only “CRC-16”. That is not an algorithm, it is a family: there are dozens of published 16-bit CRCs, they differ in polynomial, starting value, bit order and a final XOR, and picking the wrong one gives a wrong answer with no hint that anything went wrong. So this page does not ask you to choose. Paste the frame — as text, as a hex dump, or as a file — and it computes all 113 published algorithms at once, from CRC-3/GSM up to CRC-82/DARC. Find the row whose result equals the bytes you are holding and the question is answered, name and all.

The six numbers that define a CRC

When a datasheet does describe its CRC properly, it describes the Rocksoft model: width, poly, init, refin, refout and xorout. Type those in and the result appears immediately, alongside one more number that is worth more than it looks — the check value, this parameter set's own digest of the nine characters 123456789. Every published CRC states its check value, and so does every serious datasheet. If the check on this page matches the check in your document, the six numbers you typed really are the algorithm that document means, and only then is the result on the left worth trusting. It is the difference between a calculator and a guess.

Searching for the algorithm

When no name fits and no datasheet exists, give the search the frame and the checksum it carries. It runs every published model first, then brute-forces every 8-bit polynomial and every 16-bit polynomial with init and xorout at all-zeroes or all-ones and both reflection settings. Anything it reports satisfies your sample — it can miss an answer, it will never invent one. The bounds are stated rather than hidden: widths above 16 are not brute-forced, because four billion polynomials is not a search a browser tab finishes, and a sample larger than 64 KB is refused outright, because the catalog pass alone would run 113 bit-by-bit engines over the whole thing before the search proper began. Reverse lookup is for one message, not one firmware image.

Not everything at the end of a packet is a CRC

Plenty of protocols end in something simpler, and getting told “that is not a CRC at all” is a real answer. The same input is run through eight non-CRC checksums as well — sum8, sum16, xor8, fletcher16, fletcher32, adler32, the RFC 1071 internet checksum and the BSD sum(1) rotate-and-add — plus an NMEA 0183 field that takes a sentence rather than bytes, because that is how the standard defines it. All of it runs in a Web Worker inside this page: no upload, no account, and nothing to explain to anyone about the firmware you were reverse-engineering at the time.

Frequently asked questions

Which one is “CRC-32”?

Usually CRC-32/ISO-HDLC — the one in zip, gzip, PNG and Ethernet — but the bare name is also published as CRC-32 and CRC-32/ADCCP, and a file that says CRC-32C means CRC-32/ISCSI instead, which is a different polynomial entirely. The table lists every alias next to its canonical reveng name, so you can search for the name your document uses and land on the model it actually means.

My result does not match my device. What is usually wrong?

Almost never the polynomial. It is the byte range: the checksum probably covers a header your terminal is not showing you, or a length field that is counted in, or it stops one byte earlier than you think. Reflection is the runner-up — refin and refout are what separates CRC-16/ARC from CRC-16/XMODEM. Try the reverse lookup with the exact bytes you believe are covered; if it finds nothing, the bytes are the thing to change, not the algorithm.

What is the check value, and why does the page keep showing it?

It is the algorithm's digest of the nine ASCII characters 123456789, and it is the one number that lets you verify a parameter set without trusting this page. Every published CRC states it. Type your parameters, compare the check shown here with the check printed in your datasheet, and you have confirmed that both documents mean the same algorithm before a single byte of your own data is involved.

Why will reverse lookup not take my whole firmware file?

Because the first thing it does is run all 113 published models over the entire sample, before any budget or cancellation applies, and the engine is deliberately bit-by-bit so that widths like CRC-82/DARC stay exact. At 64 KB that pass takes about two seconds; at a megabyte it takes half a minute and looks exactly like a hung tab. The limit is 64 KB and the refusal happens before the search starts. Computing a CRC over a large file is fine — that is the table above, and it is one algorithm at a time.

Is a CRC good enough to detect tampering?

No, and it was never meant to be. A CRC detects accidental corruption — a flipped bit on a wire, a bad block on flash — and it does that extremely well. It is linear, so anyone who can change your data can also recompute the trailer, or work out which extra bits restore the original value. If the threat is a person rather than a noisy cable, you want a cryptographic hash, or a MAC if the file could be replaced wholesale.

Related tools