CRC32: What a Checksum Detects and What It Cannot
CRC32 is a 32 bit error detecting checksum, not a cryptographic hash. It reliably catches accidental bit flips in transfers and archives, and it offers no resistance at all to someone deliberately crafting a second input with the same value.
At a glance
- Digest size
- 32 bits
- Hex characters
- 8
- Construction
- Cyclic redundancy check, a table driven remainder over a fixed polynomial
- Standard
- Not a cryptographic standard. The usual variant uses the polynomial 0x04C11DB7 from IEEE 802.3
- Broken for collisions
- Yes, by design. Two inputs with the same CRC32 can be constructed in microseconds
- Safe for password storage
- No. Use a memory-hard password hash such as Argon2id, scrypt or bcrypt
- Available in the generator
- Yes, computed alongside the eight cryptographic digests
In detail
A cyclic redundancy check treats your input as one enormous binary polynomial and divides it by a fixed generator polynomial. The 32 bit remainder is the checksum. That structure is what makes it good at its actual job: any burst of corrupted bits shorter than 33 bits is guaranteed to change the remainder, so a truncated download or a flipped bit on a wire is caught with certainty rather than probability.
The same structure is what disqualifies it from security work. CRC32 is linear over the bits of the input, which means an attacker who wants a chosen file to land on a chosen checksum can solve for four bytes to append and hit it exactly. No search is involved. This is not a weakness that got discovered and will be patched, it is arithmetic, and it applies just as much to CRC16 and CRC64.
Where it is right: ZIP entries, PNG chunks, Ethernet frames and Gzip trailers all carry a CRC32, and all of them are protecting against accident rather than malice. It is also a reasonable cheap fingerprint for cache keys or duplicate detection inside a system you control, provided a collision is a performance problem and not a correctness or security problem.
Where it is wrong: anything a stranger can influence. Do not use CRC32 to verify a download against a published value, to deduplicate untrusted uploads, to sign an API payload, or as a database primary key derived from user input. In every one of those cases an attacker controls the input and can steer the output, and the check becomes theatre.
It is also wrong for password storage, but so is every other algorithm on this page. Passwords need a deliberately slow, memory-hard function such as Argon2id, scrypt or bcrypt, with a per-user salt and a tuned cost parameter. ToolBox does not offer a password hashing tool, and the generator here is not a substitute for one. The distinction matters: fast is the whole point of CRC32 and the whole problem for passwords.
Examples
input: "" -> 00000000
input: "abc" -> 352441c2
input: "123456789" -> cbf43926"123456789" is the standard check value used by CRC implementations to prove they are configured for the same polynomial and bit order.
original.txt CRC32 = 352441c2
attacker.txt CRC32 = 352441c2
The attacker writes any content they like, then appends four
computed bytes. No brute force is needed: the four bytes are
solved for directly from the linear equations.Things that catch people out
- There is more than one CRC32. The Gzip and ZIP variant reflects both the input and the output; other variants (CRC-32C used by iSCSI and some filesystems, or CRC-32/BZIP2) use a different polynomial or bit order and give different values for the same file. A mismatch between two tools is usually a variant difference, not corruption.
- An 8 character hex string is short enough that random collisions turn up in practice. Across roughly 77,000 items you have already crossed a 50 percent chance of a collision, so CRC32 is a poor choice of key for any collection that grows.
- Some archive tools print the CRC32 in uppercase and some in lowercase. They are the same value. The generator has an uppercase toggle for hex output if you need to match a particular listing.
Try it: Hash Generator
Paste text or drop a file and get every digest at once, in hex or Base64, with a verify tab for comparing an expected value against what you actually have.
Hash Generator
LOCAL · Browser-OnlyGenerate MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512, Keccak-256, CRC32, and HMAC hashes from text or files
MD5 is cryptographically broken and should not be used for security purposes. Use SHA-256 or SHA-512 instead.
Related Hash algorithms
All hash algorithms →MD5: 128 Bit Digests, Broken Collisions, and Remaining Uses
MD5 produces a 32 character hex digest. Collisions have been practical since 2004, preimages have not. What that distinction rules out, and what it does not.
SHA-256: The Default Choice and How It Is Used
SHA-256 gives a 64 character hex digest with no practical collision or preimage attack. Where it belongs, where it does not, and its length extension flaw.
SHA-1: Practical Collisions and What Replaced It
SHA-1 gives a 160 bit digest, 40 hex characters. Collisions became practical in 2017 and chosen prefix collisions in 2020. What still uses it and why.
SHA-384: Truncated SHA-512 and Why the Truncation Helps
SHA-384 is SHA-512 with a different starting state, cut to 384 bits. That truncation removes the length extension weakness. 96 hex characters explained.
SHA-512: 512 Bit Digests and 64 Bit Word Arithmetic
SHA-512 outputs 128 hex characters using 64 bit words and 1024 bit blocks. Why it can beat SHA-256 on 64 bit hardware, and where the extra width is pointless.
SHA3-256: The Sponge Construction and How It Differs From SHA-256
SHA3-256 gives the same 64 hex characters as SHA-256 from a completely different construction. No length extension, different failure modes, FIPS 202.
Tools for this
- Hash Generator Free online hash generator - generate MD5, SHA-1, SHA-256 hashes from any input text
- Hex Dump Viewer View hex dumps of files and text online - color-coded bytes, search, and ASCII representation