CRC32 checksum calculator
Eight hexadecimal characters from whatever you type, computed in this tab. CRC32 is not a cryptographic hash and was never meant to be one — it is a division remainder built to catch the damage wires and disks do on their own, and it is the value a ZIP file already stores for every entry inside it.
This box hashes text. For the checksum of a file, a folder, or a download you are verifying, that is the Files and Verify tools in Rocket Hash — a web page has no access to your disk.
The algorithm is worked out from the length of what you paste, then compared with the digest of the text above. To check a checksum against a file, use the Verify tool in the Mac app — it reads the file itself and gives you a plain match or no-match verdict.
The value above is not a hash, and CRC32 is not an old or weakened hash either. It comes from a different family with a different purpose: it is the remainder of a division, designed to catch the particular kinds of damage that wires, disks and radios inflict on data all by themselves. Thirty-two bits is everything it produces, which is the first clue that it answers a narrower question than the 64-character digests elsewhere on this site.
What a CRC actually computes
Take your input, treat the whole thing as one enormous binary number, divide it by a fixed 33-bit constant using a flavor of long division where addition is exclusive-OR, and keep the remainder. That remainder, with the register inverted going in and the result inverted coming out, is the CRC. The constant is the generator polynomial 0x04C11DB7 — 33 bits with the top one implied, which is why code usually carries it bit-reversed as 0xEDB88320 — and it was chosen in the 1970s because the errors real hardware makes happen to be the errors that division catches.
Nothing about that construction is secret or one-way. There is no security argument anywhere in it, and none was intended: the design target was a circuit small enough to sit in a network card and run at line rate. That is still what it is good at, and what CRC32 is used for traces the rest of the family tree.
What it guarantees, and what it does not
Because it is arithmetic rather than a one-way function, CRC32 comes with actual guarantees rather than probabilistic hand-waving. For any message it detects every single-bit error, and it detects every burst of consecutive flipped bits up to 32 bits long — not usually, not with high probability, always. A cryptographic hash cannot promise that; it only promises that an attacker cannot find an exception on purpose.
Past those guaranteed cases the odds are what you would expect from 32 bits: a randomly mangled file has about one chance in 4.3 billion of landing back on its original CRC. For a damaged download that is plenty. For anything with an adversary in it, it is worse than useless, because the linearity that makes the guarantees possible also makes the value steerable.
Given a file and any target value, you can calculate exactly which four bytes to change to make its CRC32 come out at that target. No search, no luck, no cost. That is a property of the algorithm, not a flaw in an implementation.
This is the whole difference between an error-detecting code and a checksum you can rely on. CRC32 catches a bad cable, a dying sector, a truncated copy and a flipped bit in transit. It cannot tell you a file is the file somebody published, because anyone editing the file can keep the CRC unchanged while they do it. For that question use SHA-256, and for why, choosing an algorithm lays out the cases side by side.
Why two tools report different CRC32 values
This is the single most common CRC32 problem and it is almost never a bug. “CRC32” names a family, not a function. The variants differ in which polynomial they divide by, whether the bits are processed in reverse order, what the register starts at and whether the result is inverted at the end — and each combination gives a completely different number for the same input.
| Variant | Where you meet it |
|---|---|
| CRC-32/ISO-HDLC — the one this page computes | ZIP, gzip, PNG, Ethernet, zlib, and almost everything labeled simply “CRC32” |
| CRC-32C (Castagnoli) | iSCSI, ext4 and Btrfs metadata, many databases |
| CRC-32/CKSUM | The POSIX cksum command, which also folds the file length into the value |
| CRC-32/BZIP2 | bzip2 archives; the same polynomial as the first row, processed unreflected |
So if a value disagrees with this page, check which variant produced it before assuming either is wrong. cksum on your Mac will not agree with a ZIP file's stored CRC, and that is correct behavior for both. Why two tools give different hashes covers the non-CRC reasons for a mismatch, which are mostly about bytes you did not realize were in the input.
In the variant here, an empty input gives eight zeros. Clear the box above and check — a tool that reports anything else for no input at all is computing a different CRC-32 from this one.
Where CRC32 is already running without you
Every Ethernet frame that reaches your Mac carries one and is discarded silently if it does not check out. A ZIP file stores the CRC32 of every entry it contains, which is exactly how an unarchiver knows to tell you an archive is damaged rather than handing you a broken file. A PNG stores one per internal chunk. A gzip stream keeps one of the uncompressed data in its trailer.
The practical upshot is that a ZIP archive already verifies itself, and you do not have to ask it to. Double-click the archive in the Finder and every entry's stored CRC32 is checked against the data as it is written out; an archive that reports an error instead of producing files is telling you those two numbers disagreed. So if the question is whether a ZIP survived a transfer, expanding it is already the test, and computing a checksum of the archive adds nothing to it.
If the question is whether it is the same archive the publisher built, that is a different question and the CRC32s inside cannot answer it — anyone who edited the contents recalculated them on the way out. What answers it is a digest over the .zip file as a whole, set against a value the publisher stands behind. Hashing a ZIP archive puts the two checks side by side, and verifying a download covers where the published value ought to come from.
Eight characters is not very many
There are 4,294,967,296 possible CRC32 values. That sounds generous until you collect files: by the birthday argument, a set of roughly 77,000 unrelated files is already more likely than not to contain two sharing a CRC32. At 100,000 files a coincidental match is the expected outcome, not a surprise.
That rules CRC32 out as an identity for content. It is fine as a cheap first pass — equal CRCs mean “look closer”, different CRCs mean “definitely not the same file” — and that is how some tools use it before falling back to something wider. If you are actually trying to find duplicates, finding duplicate files by hash uses a digest with room to spare.
Why your CRC32 has only seven characters
Because something stripped a leading zero. A CRC32 is a 32-bit number, and plenty of programs print it as a number rather than as a fixed-width field, so 04f1a9e2 arrives as 4f1a9e2 and looks mangled. Pad it back out to eight characters and compare again.
You will also meet CRCs written in decimal, which is what Python's zlib.crc32 and the cksum command both return. Those are the same value in a different base, not a different checksum. Convert before concluding anything.
Doing this on your Mac instead
Rocket Hash puts CRC32 under its own group heading — CHECKSUM, separate from SHA-2, SHA-3 and the legacy pair — because the distinction this page is about is one worth making in the interface too. In the Text tool the eight characters appear under that heading as you type, with a byte count for what you typed sitting just above the list of digests, which is the quickest way to settle a variant argument: a known input, a known answer, nothing to set up. Clicking the row copies that one value, so a CRC32 never leaves with a SHA-256's name on it. Text hashing is free.
For files, the Files tool is where CRC32 earns its keep next to something wider. Drop in a folder and every file underneath it is queued, each read exactly once, with every algorithm you asked for coming out of that single pass — so the cheap value and the 64-character one cost you the same wait. Each row shows the file, the folder it came from and its size, and the row's chevron opens all eight digests for that file; memory stays flat at roughly 16 MB however large the file is, and the finished list exports as a shasum-compatible manifest. That combination is the one worth having: CRC32 to sanity-check against whatever an archive or an old log already recorded, and a real digest for the record you keep. Calculating a CRC32 on a Mac walks through it, and hashing a whole folder covers the folder case properly.
Frequently asked questions
What is a CRC32 checksum used for?
Detecting accidental damage to data in transit or in storage. Ethernet frames, ZIP entries, PNG chunks and gzip streams all carry one so the receiving software can tell that something arrived corrupted. It is an error-detecting code, not a security mechanism, and it is not meant to prove where a file came from.
How long is a CRC32 checksum?
32 bits, written as eight hexadecimal characters. You will often see it with leading zeros stripped, so a seven-character value is usually an eight-character value missing a zero, and some tools print it in decimal instead of hex. All of those are the same number.
Why does my CRC32 not match the one another tool gave me?
Almost always because the two tools compute different CRC-32 variants. The common one, used by ZIP, gzip, PNG and zlib, is CRC-32/ISO-HDLC. The POSIX cksum command and CRC-32C (used by some filesystems and databases) are different functions with different answers for the same input, and neither is wrong.
Is CRC32 secure?
No, and it is not intended to be. Because a CRC is a linear function you can work out exactly which bytes to change in a file to force any CRC32 value you like, with no searching involved. Anyone modifying a file can leave its CRC32 untouched, so the value proves nothing about tampering.
Can two different files have the same CRC32?
Easily. There are only about 4.3 billion possible values, so a collection of roughly 77,000 unrelated files is already more likely than not to contain a coincidental pair. Use CRC32 to rule files out quickly, never to declare two files identical.
Is CRC32 faster than SHA-256?
Yes, it is the cheapest of the common algorithms by a wide margin. It rarely matters in practice, because reading the file off the disk takes far longer than any of these algorithms need to process it — so you can compute a proper digest for the same wall-clock time and get a far more useful answer.
How do I tell whether a ZIP archive is damaged on a Mac?
Expand it in the Finder. Every entry inside a ZIP carries the CRC32 of its own contents, and the unarchiver checks each one as it writes the file out — which is why a damaged archive reports an error rather than quietly handing you broken files. That tells you the data survived the trip; to know the archive is the one the publisher built, compute a SHA-256 of the .zip file itself — a job for an app on your Mac rather than a browser tab — and compare it against the publisher's value.