How to calculate a CRC32 checksum on Mac

A ROM database lists eight characters beside every file. A ZIP keeps eight for every member inside it. A gzip file stores the same 32 bits in its footer, a PNG repeats them after every chunk, and every Ethernet frame that has ever reached your Mac arrived with a set that the hardware checked and threw away. More CRC32s are computed on your Mac in a minute than every other checksum you will ever deliberately ask for — and they are also the ones most likely to be describing something other than what you assume.

That assumption is what this page is mostly about. A CRC32 rarely covers the file in your hands: it covers one member inside an archive, or one chunk of a PNG, or a stream as it stood before compression. The second trap is cheaper still — roughly half the CRC32 mismatches people report are a dropped leading zero, a decimal integer or an uppercase 0x prefix rather than damage. Settle what the value covers and what base it was printed in, and the comparison itself takes a second: eight characters either match or they do not.

Where the guarantee stops is the other half of the page. CRC32 catches a bad cable and is entirely indifferent to a bad actor, and unlike MD5 that is not a failure — it was never trying to do the other job. If you only need one value settled right now, the CRC32 calculator on this site does the arithmetic on any string you type, in the tab, as you type it.

What CRC32 actually computes

CRC stands for cyclic redundancy check, and what it does is division, not the scrambling a hash function performs. Your data is read as the coefficients of one enormous binary polynomial; that polynomial is divided by a fixed 33-bit one; the 32-bit remainder, with a couple of conventional twists at each end, is the checksum. The divisor is not a secret or a subtlety — every specification that uses it writes the polynomial out in full, as x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1 — and that is the same generator ZIP, gzip and PNG all use.

Everything characteristic about CRC32 follows from being a remainder rather than a digest:

• It is small and fixed. 32 bits, so eight hexadecimal characters, so 4,294,967,296 possible values — for a one-byte file and for a 40 GB one alike.
• It is cheap in hardware. That is why it ended up in network controllers, disk interfaces and file formats from the era when a checksum had to cost almost nothing.
• It is linear. The effect of changing part of the input on the output can be calculated directly rather than searched for. This is the property that makes it useless against anybody deliberate, and it is covered below.

One more thing before you compare anything: CRC32 is not one algorithm. The variant that ZIP, gzip, PNG and the ROM databases all agree on is the common one, and it is what you want by default. CRC-32C — Castagnoli, used by iSCSI, Btrfs and ext4 metadata — uses a different polynomial and produces a completely different eight characters from the same bytes. One input separates them: give a tool the letters abc and the common CRC32 answers 352441c2 where CRC-32C answers 364b3fb7. An empty input is no use for this test, because both variants return 00000000 for nothing at all.

Calculate a CRC32 on your Mac

1. Compute your own value

   For a string, click Text in the sidebar and type it — the CRC32 row appears under the CHECKSUM heading, separate from the SHA-2, SHA-3 and legacy groups, because it is a different kind of thing. For a file, drag it into Files instead, where the row’s disclosure chevron expands to show every algorithm for that file with CRC32 among them.

2. Work out what base the other value is in

   Hexadecimal is conventional but not universal. A value like 891568578 is the same checksum as 352441c2 written in decimal, which is how a few command line tools print it. Strip any 0x prefix, and convert both sides to lowercase hex before you compare — the number is case-insensitive, but string comparison is not.

3. Restore any missing leading zeros

   A CRC32 is always eight characters, but roughly one value in sixteen begins with a zero and some tools print it as a plain number with the zeros stripped. If the value you were given is six or seven characters, pad it on the left until it is eight. A checksum of a1b2c3 is almost certainly 00a1b2c3.

4. Compare the eight characters

   This is the one mercy CRC32 offers: eight characters is short enough to read with your own eyes, so there is nothing to paste into a comparison tool and no risk of missing a difference in the middle of a long string. They match or they do not — a single changed bit anywhere in the file will change this value.

Where the eight characters came from

The commonest CRC32 mismatch is not corruption at all: it is comparing a checksum of one thing against a checksum of something else. These values are usually embedded inside a container, and what each one covers is specific.

The ZIP case is worth dwelling on because it trips up so many people. A .zip stores a CRC32 for the original contents of each file it contains, calculated before compression. Computing the CRC32 of the archive itself gives you a number about the compressed container, which was never going to equal any of the numbers inside it. Hashing a ZIP archive pulls the two checks apart properly.

So the real work is lining both sides up on the same bytes. Double-click the archive to expand it, drop the extracted file you care about into Files, and open the disclosure chevron at the end of its row: CRC32 sits there with the other seven algorithms, all from the single read the file already got. Set the Algorithm control in the toolbar to CRC32 and the collapsed row carries those eight characters as well, which is then what the row’s copy button hands you — worth using in a value this short, because one mistyped character is indistinguishable from corruption.

There is nothing to save by narrowing it, though: the file is read once however many digests you asked for, so reaching for CRC32 under the chevron leaves you holding a SHA-256 worth keeping as well as the eight characters the database wanted. For a string rather than a file, Text puts CRC32 under its CHECKSUM heading as you type, free.

If the archive and the extracted member both end up in the list, the two rows are easy to mix up, because an archive and its contents often share a name. Each row carries the containing folder under the file name, so the copy still sitting in ~/Downloads and the one you expanded into a folder of its own stay distinguishable, and the size on the row is a second check — a member and the archive around it rarely weigh the same. The eight hexadecimal characters under the CHECKSUM group on the member are the ones a ROM database or an archive listing is talking about.

What 32 bits can and cannot guarantee

CRC32 gives you something a cryptographic hash does not: a proof rather than a probability, for whole classes of error. A correctly chosen CRC of this length detects every single-bit error, and every burst of consecutive flipped bits up to 32 long, with certainty. Anything messier than that gets past it with a probability of about one in 4.3 billion. That is why the design turns up in hardware again and again: the failure modes of a cable, a radio link or a platter are exactly the errors a CRC is built to catch.

That last point is a genuinely different kind of weakness from the one MD5 and SHA-1 have. Those two were designed to resist forgery and were eventually beaten at it. CRC32 was never designed to resist anything; it is a self-check, and a self-check assumes the only adversary is physics.

The second limit is arithmetic. With only 4.3 billion possible values, two unrelated files will share a CRC32 far sooner than intuition suggests — at around 77,000 files you are past even odds, and in a folder of 100,000 you should expect a clash. So CRC32 cannot answer “are these two files the same?” at any scale, and it has no business being used to deduplicate anything. Finding duplicates by hash explains why that job needs a 256-bit digest.

When CRC32 is the right choice

Two cases, and they are narrower than they used to be. The first is when you have no choice: the other side published a CRC32, so a CRC32 is what you compare. The second is when four bytes is all the room you have — a record format, an embedded header, a protocol field.

The historical third reason, that it is fast, has quietly stopped applying on a Mac. SHA-256 runs at roughly 2 GB/s on Apple Silicon, which is quicker than most drives can feed it, so the algorithm is not what you are waiting for — the disk is. Asking for CRC32 instead of SHA-256 on a modern machine saves you no measurable time and gives up every useful property. If you are picking for yourself rather than matching somebody else, the decision tree for choosing an algorithm will not send you here.

Troubleshooting

My value is shorter than eight characters

Leading zeros were stripped by whatever printed it, because it was treated as a number rather than as a fixed-width checksum. Pad it back out to eight on the left. This is also why a CRC32 of exactly 0 sometimes appears where 00000000 belongs — which is the correct value for an empty file.

The CRC32 I computed does not match the one in the ZIP

You almost certainly hashed the archive rather than the file inside it. The CRC in a ZIP listing describes one member’s uncompressed contents, so to check it you need to extract that member and compute the CRC32 of the extracted file. Comparing against the .zip itself will never agree, no matter how intact everything is.

Another tool reports a completely different number

Ask which CRC it computed before you suspect the file. The POSIX checksum that Unix systems have shipped for decades appends the file’s length to the data before dividing, so it disagrees with the ZIP and PNG variant by design, and it prints a decimal integer rather than hex on top of that. Neither form is wrong — they answer slightly different questions — but only one of them is comparable with a ROM database or an archive listing, and that is the eight hexadecimal characters in the CHECKSUM group.

It is eight characters and still will not match

Three candidates, in order. It may be CRC-32C rather than CRC32, which is a different polynomial with identical-looking output. It may be the first eight characters of a longer digest, truncated by a tool or by a column width. Or the bytes may be reversed, which happens when a value is read out of a binary header without accounting for byte order.

Two different files have the same CRC32

That is expected behavior, not a bug, and it is the single best argument against using CRC32 as an identifier. With a few tens of thousands of files the birthday arithmetic catches up with you. If you want a value that distinguishes files rather than merely detecting damage to one, verifying a file after a transfer shows the same workflow done with a digest that has room to be unique.

Frequently asked questions

How many characters is a CRC32 checksum?

Eight hexadecimal characters, which is 32 bits or 4 bytes. The leading zeros are part of the value even when a tool prints the checksum as a plain number and drops them, so pad anything shorter out to eight before you compare it. For contrast, MD5 is 32 characters, SHA-1 is 40 and SHA-256 is 64.

Is CRC32 a secure hash?

No, and it was never intended to be. CRC32 is linear, which means anyone can calculate exactly which bytes to change in a file to give it any CRC32 they want — no searching, no expensive hardware, no skill. It is excellent at detecting accidental damage and worthless against anybody deliberate. Use SHA-256 whenever the question is whether a file is authentic rather than whether it is intact.

Why doesn’t my CRC32 match the one inside my ZIP file?

Because a ZIP stores a CRC32 for each file it contains, computed on that file’s original uncompressed contents, not on the archive. If you compute the CRC32 of the .zip you get a number describing the compressed container, which will never equal the values the archive lists internally. Extract the member first, then check that.

Can I get a CRC32 for every file in a folder at once?

Yes. Drop the folder into the Files tool and every file underneath it becomes its own row, streamed and checksummed in turn while the status bar counts off what is done. Expanding a row shows CRC32 alongside the other seven algorithms for that file, all from one read of it, and the export button turns the finished run into a file you can keep. There is no single CRC32 for a folder — you get one per file, which is the only thing a per-file checksum can honestly mean.

Is CRC32 good enough to verify a download?

It will reliably catch a truncated or corrupted transfer, which is the commonest thing that goes wrong. What it cannot do is tell you the file is the one the publisher built, since a CRC32 can be matched deliberately in an instant. If the publisher offers a SHA-256 as well, use that one; if CRC32 is all they give you, checking it is still better than checking nothing.

CRC32 or MD5 for checking that files copied correctly?

MD5, if those are the only two options, and SHA-256 in preference to both. The issue with CRC32 at scale is not speed but space: with only 4.3 billion possible values, two unrelated files in a large set will share one by accident, so a match stops being meaningful. MD5’s 128 bits push the accidental-collision threshold out to around 18 quintillion files, which no real collection reaches, even though it is no longer safe against deliberate ones.