CodeKitHubWhat Is This Tool?
CRC stands for Cyclic Redundancy Check, an error-detecting code first described in the 1975 paper by W. Wesley Peterson and D.T. Brown, and later formalized in references such as Ross Williams' "A Painless Guide to CRC Error Detection Algorithms" and the ITU-T / ISO 3309 standards. A CRC treats a message as a large binary number and divides it by a fixed generator polynomial; the remainder of that division is the checksum. Because polynomial division is cheap to compute in hardware and software alike, CRCs became the default error-check for storage and transmission systems.
CRC-32 — specifically the variant with polynomial 0xEDB88320, an initial value of 0xFFFFFFFF and a final XOR of 0xFFFFFFFF — is standardized in IEEE 802.3 (Ethernet) and used as the checksum inside ZIP and gzip archives, PNG image files, and countless network and storage protocols. It is by far the most commonly requested CRC variant, which is why it's the default algorithm in this tool. CRC-16/CCITT-FALSE (polynomial 0x1021) and CRC-16/MODBUS (polynomial 0x8005, reflected) are two widely used 16-bit variants found in serial protocols like Modbus RTU, XMODEM, and various embedded/industrial communication standards.
It's important to understand what a CRC is not: it is not a cryptographic hash. CRCs are fast, linear functions with no resistance to deliberate manipulation — it is straightforward to construct a different message that produces the same CRC value. They are excellent at catching the kind of random bit-flips caused by noisy transmission lines, disk errors, or truncated downloads, but they provide zero protection against an adversary who wants to tamper with data undetected.
Why Use It?
- You're bit-banging a Modbus RTU driver and the slave device keeps rejecting your frames — paste the exact byte sequence here with CRC-16/MODBUS selected to check whether your firmware's CRC routine matches the reference value before debugging anything else.
- You just wrote a CRC-32 table-generation routine in C or Rust from scratch and want to sanity-check it — run the standard "123456789" test vector through this tool and confirm you get 0xCBF43926 before trusting your implementation on real data.
- A ZIP extraction tool is throwing a CRC mismatch error on one entry and you're not sure if the archive is actually corrupt — recompute the CRC-32 of the extracted bytes here and compare it against the value stored in the ZIP's local file header.
- You're implementing XMODEM or a similar serial protocol and the spec just says "append the CRC-16" without much elaboration — compute it here first so you know what the correct trailing bytes should look like before you start debugging your transmit code.
- You inherited an embedded project with an undocumented checksum field and suspect it's CRC-16/CCITT-FALSE rather than CRC-16/MODBUS — try both variants against a known payload and see which one matches the value the device actually sends.
- 100% local: your text or file is processed entirely in JavaScript in your browser, so nothing is uploaded anywhere.
How to Use
- Choose the "Text" tab and paste or type your input, or switch to the "File" tab and choose a file from your device.
- Select the CRC algorithm: CRC-32 (IEEE 802.3, the default and most common), CRC-16/CCITT-FALSE, or CRC-16/MODBUS.
- The checksum updates automatically, shown in hexadecimal, decimal and binary.
- Click "Copy" next to any result to copy it to your clipboard.
Example
Input
123456789Output
0xCBF43926 (3421780262)This is the standard published CRC-32 (IEEE 802.3) test vector: the CRC-32 of the ASCII string "123456789" is always 0xCBF43926. You can check this tool's output against any other correct CRC-32 implementation using this exact string.
CRC vs. cryptographic hashes (MD5 / SHA)
Both CRCs and cryptographic hashes reduce data to a fixed-size fingerprint, but they solve different problems and are not interchangeable.
| Property | CRC (e.g. CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Purpose | Detect accidental corruption | Detect intentional tampering / verify integrity |
| Speed | Extremely fast, simple hardware/software | Slower, more computation per byte |
| Collision resistance | None — trivial to engineer on purpose | Designed to be computationally infeasible (SHA-256) or broken for MD5 |
| Typical size | 16 or 32 bits | 128 bits (MD5) or 256 bits (SHA-256) |
| Common uses | ZIP/gzip, PNG, Ethernet, Modbus, storage | File integrity checks, digital signatures, password storage (with salting) |
The three CRC variants at a glance
Each variant is defined by its polynomial, initial value, whether input/output bits are reflected, and the final XOR — get any one of these wrong and you'll compute a technically valid but incompatible checksum.
| Variant | Polynomial | Init value | Reflected | Final XOR | Common use |
|---|---|---|---|---|---|
| CRC-32 (IEEE 802.3) | 0xEDB88320 | 0xFFFFFFFF | Yes (in & out) | 0xFFFFFFFF | ZIP, gzip, PNG, Ethernet |
| CRC-16/CCITT-FALSE | 0x1021 | 0xFFFF | No | 0x0000 | XMODEM, telecom protocols |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | Yes (in & out) | 0x0000 | Modbus RTU serial frames |
Related tools
If you need a cryptographic checksum instead of an error-detection CRC, these tools are a better fit.
→ Multi-Algorithm Hash Generator · MD5 Generator · HMAC Generator
Frequently Asked Questions
What is a CRC used for?
A CRC (cyclic redundancy check) is an error-detection code appended to a block of data so the receiver can recompute it and confirm the data wasn't accidentally corrupted during storage or transmission. It's built into standards like IEEE 802.3 Ethernet framing, the ZIP and gzip file formats, PNG images, and many serial and industrial protocols such as Modbus.
Is CRC-32 the same as MD5 or SHA-256?
No. CRC-32 is a fast, linear error-detection checksum with no security properties — it's trivial to construct two different inputs with the same CRC-32 value on purpose. MD5 and SHA-256 are cryptographic hash functions designed to make that kind of deliberate collision computationally infeasible. Use CRC-32 to catch accidental corruption (a scratched disk, a dropped network packet); use a cryptographic hash from our [Hash Generator](/hash-generator) or [MD5 Generator](/md5-generator) when you need tamper-evidence or integrity guarantees against an adversary.
Which CRC-32 variant does this tool use?
The IEEE 802.3 / ZIP / PNG variant: polynomial 0xEDB88320 (the bit-reflected form of 0x04C11DB7), initial value 0xFFFFFFFF, input and output reflected, and a final XOR of 0xFFFFFFFF. This is the variant used by Ethernet, ZIP, gzip and PNG, and the one that produces 0xCBF43926 for the ASCII string "123456789" — the standard published test vector for verifying a CRC-32 implementation.
What's the difference between CRC-16/CCITT-FALSE and CRC-16/MODBUS?
Both are 16-bit CRCs but with different polynomials and parameters. CRC-16/CCITT-FALSE uses polynomial 0x1021 with an initial value of 0xFFFF and no bit reflection; it's common in protocols like XMODEM and various telecom standards. CRC-16/MODBUS uses polynomial 0x8005 (reflected as 0xA001), also with an initial value of 0xFFFF, but with input and output reflected — it's the checksum Modbus RTU appends to every serial frame. They will produce different results for the same input, so it's important to pick the variant your target protocol actually specifies.
Can I compute the CRC of a file, not just text?
Yes. Switch to the "File" tab and choose a file from your device — the tool reads its raw bytes locally in the browser (via the File API) and computes the checksum over exactly those bytes, the same way a ZIP or PNG reader would.
Is my data uploaded to a server?
No. Both the text and file computation run entirely client-side in JavaScript using a standard table-based CRC algorithm. Nothing you type or upload ever leaves your browser.
Why does my hand-rolled CRC-32 implementation give a different result than this tool?
The most common cause is a mismatched initial value, final XOR, or bit-reflection setting — CRC-32 isn't one fixed algorithm, it's a family of parameters, and the IEEE 802.3/ZIP/PNG variant this tool uses starts at 0xFFFFFFFF, reflects both input and output, and XORs the final result with 0xFFFFFFFF. Skipping any one of those steps produces a different, equally "valid" but incompatible checksum. Test your implementation against the "123456789" → 0xCBF43926 vector to isolate which step is off.
Is there a size limit for the file upload?
There's no artificial limit enforced by the tool, but very large files may be slow since the CRC is computed byte-by-byte in JavaScript in your browser. For typical firmware images, ZIP entries, or protocol frames — from a few bytes up to tens of megabytes — performance is effectively instant.
Does whitespace or line-ending style affect the CRC of pasted text?
Yes — a CRC is computed over the exact bytes of your input, so a trailing newline, a stray space, or Windows-style CRLF versus Unix-style LF line endings will all produce a different checksum even if the visible text looks identical. If you're matching a checksum from another tool, paste exactly what that tool hashed, including any trailing whitespace, or better, use the File tab to compare raw bytes directly.
Can two completely different files have the same CRC-32 value?
Yes, and this is expected, not a bug — CRC-32 only has 2^32 possible outputs, so collisions are mathematically guaranteed to exist for large enough datasets, and they're also trivial to construct deliberately since CRC-32 has no cryptographic collision resistance. This is exactly why CRC-32 is fine for catching accidental corruption but unsuitable for verifying that a file hasn't been tampered with.
Which CRC variant should I use if the protocol documentation doesn't specify parameters?
Start with the variant most associated with that protocol family: CRC-16/MODBUS for Modbus RTU serial communication, CRC-16/CCITT-FALSE for XMODEM and many telecom-derived protocols, and CRC-32 (IEEE 802.3 variant) for anything ZIP-, gzip-, PNG-, or Ethernet-adjacent. If neither matches a known-good frame from the real device, the protocol may use a nonstandard polynomial or parameter set outside what this tool covers.