CRC-32 Calculator - Checksums for Text, Hex and Files

CRC-32 is used wherever a cheap, near-certain check for accidental corruption is worth more than a security guarantee. Every ZIP archive stores one per entry in its central directory, and unzip verifies it on extraction so a truncated or bit-rotted file is reported instead of silently producing garbage. gzip and zlib append a CRC-32 to their compressed streams, which is why a corrupted .gz file produces a checksum error rather than a mysterious decompression error. PNG stores a CRC-32 in every single chunk, both to validate each chunk independently and to let a decoder stop at the first bad chunk. MPEG-2 transport streams carry one per packet, and the Ethernet frame check sequence is a CRC-32, computed in hardware on every frame that crosses a switch. In each case the threat model is the same: noise, hardware decay, partial writes and mismatched versions, not a motivated attacker.

No, and using it for passwords or for authenticating a download from an untrusted source would be a serious mistake. A CRC is a linear function over the field GF(2), which means XORing the same difference into two messages produces the same difference in their checksums. Anyone who knows one message and its checksum can therefore construct a different message, differing in as few as four bytes, that carries any checksum they choose. That is a forgery requiring no cleverness and no search. CRC-32 is also only 32 bits wide, so an attacker can precompute a collision in a few seconds of GPU time for a chosen plaintext. It has no key, no salt, no work factor and no avalanche behaviour, so it provides none of the one-wayness, unpredictability or brute-force resistance that password storage or code signing depends on. Use a cryptographic hash such as SHA-256 for integrity against an adversary, and a password-specific function such as Argon2id or bcrypt for anything credential-shaped.

Because the two names describe the same algorithm wrapped around slightly different framing. The CRC-32b row in this calculator runs the identical algorithm over your bytes with one trailing 0x00 byte appended, and that extra byte changes the register state, so every value shifts. The purpose of such a variant is to distinguish a payload from its own terminator, so a stream that legitimately ends in a zero byte cannot be confused with one that ends there by accident. Worth knowing: the term is used inconsistently in the wild. The BZIP2 variant, usually written CRC-32/BZIP2 and the one identified by the standard check value 0xCBF43926 for the string 123456789, appends four zero bytes rather than one, and is a different function again. If you are interoperating with a specific tool or format, check what that implementation actually appends instead of trusting the name.

It is the reversed form of the CRC-32 generator polynomial 0x04C11DB7, and it appears in essentially every software implementation of CRC-32 you will meet. The generator polynomial defines which bit patterns are treated as errors. Its normal, forward bit order is the textbook representation, but the reflected order lets the whole computation run right to left through the bytes, which needs one table lookup and one shift per byte instead of eight conditional shifts. In the reflected implementation the polynomial value 0x04C11DB7 reverses to 0xEDB88320, and each of the 256 table entries is generated by starting from a byte value and applying that reversal loop eight times: if the low bit is set, XOR the accumulator with 0xEDB88320 and shift right, otherwise just shift right. Building the table from that definition, as this tool does, is safer than pasting a 256-entry array, because it removes any chance of the shipped table drifting away from the definition it claims to implement.

Because the output space is only 32 bits, so there are roughly 4.3 billion distinct checksums to share among every possible message, and some messages must inevitably share one. Working through the birthday paradox, the number of messages you need before a collision becomes likely is about the square root of 2^32, which is 65536, so random data hits a duplicate CRC somewhere in that region. Real files are worse than random, because structured documents differ in a few predictable places. This is not a flaw in the design, it is the design working as intended. A CRC-32 catches every single-bit error and every burst error up to 32 bits with certainty, which covers essentially all accidental corruption from noise, decay and bad transfers. What it cannot do is establish identity against an adversary, because an adversary can construct a collision deliberately in seconds. If you need collision resistance, you need a cryptographic hash.

Compute the CRC-32 of the file here and compare it with the checksum the publisher or transfer system recorded. If they match, the file arrived without corruption. Many tools already do this for you, since unzip verifies each entry, gzip and zlib verify the stream trailer, and browsers verify PNG chunks while decoding, but computing the value yourself is the quickest way to confirm what a specific tool produced, and it is the only way when you have an unusual format with no built-in verification. Choose File mode, select the download, and read the CRC-32 of file output. One important caveat: a matching CRC-32 proves the file is the one the publisher generated only if you trust the publisher. If the download could have been tampered with in transit, an attacker with that ability can craft a different file with the same checksum, which is exactly why signed releases such as GPG or Sigstore signatures exist alongside checksums.

No. The calculator is a client-side component: the JavaScript in your browser reads your text, your hex bytes or the file you selected, builds the CRC-32 table in memory and runs the checksum loop locally. Nothing is transmitted over the network, nothing is written to a server log, and nothing is persisted after you close the tab. For file mode this is implemented with the browser File API, which reads the file from your local disk into memory on demand. That matters practically, not just for privacy: you can checksum a multi-gigabyte disk image or a confidential archive without waiting on an upload, and without handing a third-party service a copy of data that may be regulated or personally identifying.