# CRC Calculator > Compute every named CRC at once, enter your own Rocksoft parameters, or work backwards from data plus a checksum to find the algorithm that produced it. - URL: https://bytescope.dev/en/crc-calculator/ - Locale: en · Also: [ja](https://bytescope.dev/ja/crc-calculator.md) · [zh-Hant](https://bytescope.dev/zh-Hant/crc-calculator.md) - Runs: Your bytes never leave your browser — every checksum is computed locally. - Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile. - Updated: 2026-09-08 ## What it does ### 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. ## Limits Does not compute cryptographic hashes (use file-hash), and does not brute-force CRCs wider than 16 bits; reverse lookup takes a sample of at most 64 KB, not a whole file. ## Machine output Copy JSON copies an envelope `{ tool, url, generatedAt, userAgentHint, result }`. `tool` is `"crc-calculator"`; `result` is the CRC / checksum snapshot below. CRC values are hex strings (including widths above 32 bits). The input text, hex dump, file bytes, file name, and hex preview are omitted. - `byteLength` (number | null) — Input size in bytes. `null` = size was not supplied. - `custom` (object | null) — Custom Rocksoft model on screen. `null` = parameters were not valid so nothing was computed. Fields: `width`, `poly`, `init`, `xorout` (hex strings), `refin`, `refout` (booleans), `value` (hex digest of the input, or `null` if not computed), `check` (hex digest of ASCII `"123456789"`, or `null` if not computed), `matches` (catalog name, or `null` when computed with no match). - `catalog` (object) — Named models in on-screen table order, capped at 200. `rows` is the copied list (each: `name`, `aliases`, `width`, `value`, `check`, `poly`, `init`, `refin`, `refout`, `xorout`). `truncated` is `true` when more rows exist than were copied. `totalCount` is the real row count, not the copied length. - `reverseLookup` (object | null) — `null` = reverse search was not run. When present: `hits` (capped at 200; each `kind` is `"catalog"` or `"search"`, plus `name` or `null`, `width`, `poly`, `init`, `refin`, `refout`, `xorout`), `truncated`, `totalCount` (real hit count). Empty `hits` with `truncated` false means the search ran and found nothing. - `checksums` (array of objects) — Non-CRC checksums in on-screen order. Each: `id`, `value` (hex), `decimal`, `bits`. Empty when they have not been computed. - `nmeaChecksum` (string | null) — NMEA checksum as two lowercase hex digits. `null` = no sentence was entered. ## FAQ ### 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 - [File Hash](https://bytescope.dev/en/file-hash.md) — SHA-256 and friends over a whole file, when you need a hash and not a CRC. - [Hex Viewer / Editor](https://bytescope.dev/en/hex-editor.md) — Open the bytes, find the field the checksum covers, and edit it. - [Bitwise Calculator](https://bytescope.dev/en/bitwise-calculator.md) — Shifts, masks and a bit grid, for the register the polynomial lives in.