CRC-32 is an error detecting code borrowed from communications engineering. It exists to catch the kinds of damage that hardware and transmission cause: flipped bits, dropped bytes, truncated transfers. It is extremely good at that job, it is very fast, and it is not remotely a cryptographic function.
That distinction runs through this whole page. A CRC tells you whether a file survived a copy. It cannot tell you whether somebody changed the file on purpose, because producing a different file with the same CRC takes seconds on a laptop. Treat the result as a smoke alarm rather than a lock.
What a CRC32 checksum generator can and cannot tell you
A 32 bit CRC detects every single bit error, every double bit error, every odd number of bit errors and every burst of corruption up to 32 bits long. Those guarantees are mathematical properties of polynomial division, not statistical hand waving, which is why the algorithm has survived in hardware since the 1970s.
Against a person, none of that helps. CRC-32 is linear, so given any file and any target checksum an attacker can work out exactly which four bytes to change to hit that target. Appending a short crafted suffix is enough. Anything where somebody might benefit from substituting a file needs SHA-256 instead.
- Use it to confirm a copy, a download or an archive extraction did not corrupt data.
- Use it to match a CRC value that a zip listing, a ROM database or a build log already printed.
- Use it as a cheap index key for spotting probably identical files before a fuller comparison.
- Never use it to verify a download from an untrusted source, to sign anything, or to store a password.
CRC-32 is an error detecting code, not a hash
People call the output a hash because it looks like one, but the design goals are different. A cryptographic hash aims to make collisions infeasible to find. A cyclic redundancy check aims to make accidental collisions structured and predictable, so an engineer can prove exactly which error patterns will always be caught.
The arithmetic reflects that. The message is treated as a very long polynomial over the binary field and divided by a fixed generator polynomial, and the remainder is the checksum. Division is linear, so the checksum of two combined messages relates predictably to the checksums of the parts. Predictability is exactly what a hash must not have.
There is a practical corollary. With only 32 bits of output, two unrelated files collide by chance roughly once in four billion comparisons, which sounds rare until you run it across a library of a hundred thousand files. For deduplication at scale, use a CRC as a fast pre filter and confirm the survivors with a real digest.
Where CRC-32 already exists in files you use
Zip stores a CRC-32 for every entry in both the local header and the central directory, which is how an extractor knows a member decompressed correctly. Gzip appends the CRC-32 of the uncompressed data plus its length to the end of the stream. PNG puts a CRC-32 after every chunk, covering the chunk type and data.
Ethernet frames carry a frame check sequence using the same polynomial, and so do SATA, MPEG-2 transport streams and countless firmware image formats. When a tool reports a CRC mismatch on any of these, it is telling you the container detected damage, not that anybody tampered with it.
How this CRC32 checksum generator computes the value
The tool builds the conventional 256 entry lookup table from the reflected CRC-32 polynomial 0xEDB88320, starts the register at 0xFFFFFFFF, folds one byte at a time through the table and finally inverts the register. That is the bit reflected form used by zip, gzip, PNG and zlib, so the number matches what those tools report.
Unlike a cryptographic digest, a CRC is genuinely incremental, so this CRC32 checksum generator streams a file through in slices and never holds the whole thing in memory. A file larger than available RAM is fine here in a way it would not be for SHA-256, and the progress bar reports real read position rather than an estimate.
Reading the output: hexadecimal, decimal and byte order
The same 32 bit value gets written down in several ways, which is the usual reason two tools appear to disagree. Zip listings and PNG dumps normally print eight lowercase hexadecimal digits. Some libraries return a signed 32 bit integer, so a value above 2147483647 shows up negative. This tool prints unsigned decimal alongside the hexadecimal so both conventions are visible.
Byte order is the other trap. The checksum is a number, not a byte string, so writing it into a file requires a choice: gzip stores it little endian, PNG stores it big endian. If you are comparing against bytes read from a container rather than against a printed number, check which end the format writes first before concluding the file checksum is wrong.
| Property | CRC-32 | SHA-256 |
|---|---|---|
| Output size | 32 bits | 256 bits |
| Purpose | Error detection | Cryptographic integrity |
| Forging a match | Seconds | Not feasible |
| Incremental | Yes, byte at a time | Not through Web Crypto |
| Used in | Zip, gzip, PNG, Ethernet | Signatures, package locks, TLS |
How to calculate a CRC-32 checksum
- 1
Choose text or file
Text mode hashes the UTF-8 bytes of what you type. File mode reads the exact bytes on disk with no interpretation.
- 2
Add the input
Paste your text, or drop a file onto the drop area. Files are streamed locally and never uploaded anywhere.
- 3
Run the calculation
Press calculate. The eight digit hexadecimal value and its unsigned decimal equivalent both appear.
- 4
Compare with an expected value
Paste a CRC from a zip listing or build log into the comparison box to confirm the two agree.
Related tools worth bookmarking
Sources and further reading
- RFC 1952: GZIP file format specificationDefines the CRC-32 used here, including the exact polynomial and the little endian storage in gzip.rfc-editor.org
- W3C: Portable Network Graphics specificationSpecifies the per chunk CRC-32 in PNG, with a sample implementation of the same lookup table approach.w3.org
- MDN: Blob.arrayBufferThe browser method used to read each file slice, which is what lets the checksum stream without buffering.developer.mozilla.org
Frequently asked questions
Common questions about the crc32 checksum generator.
No. CRC-32 is linear, so anyone can modify a file and adjust a few bytes to restore the original checksum in under a second. It reliably detects accidental corruption, but it offers no protection against deliberate substitution. Use SHA-256 when the source is not already trusted.
Almost always because the other tool uses a different CRC-32 variant, prints the result as a signed integer, or writes the bytes in the opposite order. This tool implements the reflected IEEE variant used by zip, gzip, PNG and zlib.
With 32 bits of output, two unrelated files match by chance about once in four billion pairs. That is fine for a single verification but becomes likely across a large library, so use a longer digest for deduplication at scale.
Yes. A cyclic redundancy check is incremental, so the file is streamed through in slices and only a small buffer is held at any moment. Files larger than your available memory work here, which is not true of the Web Crypto digest methods.
No. The lookup table and the folding loop run in JavaScript inside your browser tab, so the bytes never leave your device. There is no server involved, which you can confirm by watching the network panel during a run.