Updated · Built and checked by the PlinzoTools team, formulas tested against published sources
Compute the CRC-32 checksum of any text.
Enter text to compute its CRC-32 checksum (the algorithm used by ZIP, PNG, and gzip).
CRC-32 (Cyclic Redundancy Check, 32-bit) is a widely used checksum algorithm for detecting accidental data corruption -- it's the checksum built into ZIP archives, PNG image files, and gzip compression. This tool computes the CRC-32 checksum of any text you enter.
Enter text. The 8-character hexadecimal CRC-32 checksum appears instantly.
The text's UTF-8 bytes are processed through the standard IEEE 802.3 polynomial using a precomputed 256-entry lookup table -- the same algorithm and polynomial used by ZIP, PNG, and gzip, so this result matches what those tools compute for the same input bytes.
For cryptographic hashing (a different, stronger purpose than error-detection checksums) instead, see the existing Hash Generator.
The tool outputs eight uppercase hexadecimal digits, always zero-padded to full length. A checksum that would naturally start with zeros, such as 00A1B2C3, still displays all eight characters, which matters when you compare it by eye or with a script. The value is the standard CRC-32 result with the usual initial value and final inversion, and the tool shows a prompt until you enter at least one character.
Suppose you keep a short configuration snippet in two places and want to confirm they match. Paste the first copy, note the checksum, then paste the second. If the eight digits agree, the two texts are almost certainly identical byte for byte. If they differ, something changed, even if you cannot see it. Common invisible culprits are trailing whitespace, a tab replaced by spaces, or a non-breaking space pasted from a web page. Changing a single character, even one letter from uppercase to lowercase, will change the output, and that sensitivity is exactly what makes the checksum useful for spotting accidental edits.
A 32-bit value has only about four billion possible outcomes. That is plenty to catch random corruption in a small input, but it means different inputs can share the same checksum, and with enough distinct inputs collisions become likely. A match is strong evidence of an accidental-error-free copy, not proof of identity. It is also not a security feature: nobody should rely on it to detect deliberate tampering, to store passwords, or to sign anything. For those purposes a cryptographic hash is the appropriate tool.
ZIP tools list a CRC-32 for each archived file, PNG chunks carry one, and gzip stores one in its trailer. This tool lets you see the mechanism on small text samples, which is useful for teaching, for debugging a home-made implementation against a known reference, or for sanity-checking test vectors in your own code.
No -- CRC-32 is designed to detect accidental data corruption efficiently, not to resist deliberate tampering; it's trivial to construct different inputs with the same CRC-32 checksum on purpose, which is fine for error-detection but unsuitable for security purposes. Use a real cryptographic hash (see the Hash Generator) for integrity against intentional tampering.
It's fast to compute and effective at catching the kind of random bit-flip corruption that can occur during file storage or transfer -- exactly the failure mode ZIP's format was designed to detect, not malicious tampering.
Yes -- CRC-32 operates on raw bytes, and since the same text can encode to different byte sequences under different encodings (UTF-8 vs. UTF-16, for instance), this tool's UTF-8-based result may not match a checksum computed from a different encoding of the same visible text.
The most common reasons are a different text encoding, hidden whitespace or line-ending differences, or the other tool using a different CRC variant. This tool uses the standard IEEE CRC-32 over the UTF-8 bytes of your text.
Yes. With only 32 bits of output, collisions are possible and can even be constructed on purpose, which is why CRC-32 is for error detection only.
Yes. Uppercase and lowercase letters are different bytes, so changing case changes the checksum.
Reference: MDN Web Docs