Which CRC-32 variant does this use?

It uses the IEEE 802.3 variant, the same one in zlib, gzip, PNG, and Ethernet. The reflected polynomial is 0xEDB88320, the initial value is 0xFFFFFFFF, and the result is XORed with 0xFFFFFFFF at the end.

Why does my checksum differ from another tool?

Different CRC-32 variants exist (CRC-32C/Castagnoli, CRC-32/BZIP2, JAMCRC) with different polynomials or bit reflection. This tool implements the common zlib/IEEE variant. Also confirm both tools encode the text the same way; this one uses UTF-8.

Is CRC-32 a secure hash?

No. CRC-32 detects accidental changes like transmission errors or corruption, but it is trivial to forge. Never use it for passwords, signatures, or security. Use SHA-256 or similar for those.

How is non-ASCII text handled?

The input is encoded as UTF-8 first, so a character like é becomes two bytes (0xC3 0xA9) and a CJK character becomes three bytes. The checksum is computed over those raw bytes, and the tool shows the resulting byte length.

Does my text leave the browser?

No. The CRC-32 is computed locally in JavaScript using a precomputed lookup table. Nothing is uploaded to a server, so it is safe for private or sensitive strings.

CRC32 Checksum Calculator

The CRC-32 (Cyclic Redundancy Check, 32-bit) is a fast checksum used to detect accidental data corruption. This tool encodes your text as UTF-8 and computes the IEEE 802.3 CRC-32 over those bytes, the same checksum used by zlib, gzip, PNG, ZIP, and Ethernet frames.

How it works

CRC-32 treats the input bytes as the coefficients of a large binary polynomial and divides it (modulo 2) by a fixed generator polynomial, keeping the remainder. The implementation here uses the table-driven reflected method:

crc = 0xFFFFFFFF
for each byte b:
    crc = TABLE[(crc ^ b) & 0xFF] ^ (crc >>> 8)
result = crc ^ 0xFFFFFFFF

TABLE is a 256-entry lookup precomputed from the reflected polynomial 0xEDB88320. The initial value 0xFFFFFFFF and the final XOR with 0xFFFFFFFF are part of the standard IEEE variant, which is why an empty input yields 00000000 and the classic test phrase yields a well-known value.

Tips and notes

The well-known test vector "The quick brown fox jumps over the lazy dog" produces the CRC-32 414fa339.
CRC-32 is for integrity, not security. A bit-flip in transit is reliably detected, but anyone can craft a different message with the same checksum.
If you need CRC-32C (used by iSCSI, ext4, and many storage systems), note it uses a different polynomial and will not match the value here.
Encoding matters: the same visible string in UTF-8 versus UTF-16 produces different bytes and therefore a different checksum.