CRC32 Checksum Calculator

CRC32 is a fast 32-bit checksum used everywhere from ZIP archives to PNG images to Ethernet frames. Paste text here to get its CRC32 value in both hexadecimal and unsigned-decimal form, computed with the standard IEEE polynomial so it matches the values produced by zip, gzip, and most programming libraries.

CRC32 (hex)
CRC32 (hex, 0x)
CRC32 (decimal)
UTF-8 bytes hashed

How to use the CRC32 Checksum Calculator

Type or paste text into the box. The CRC32 value updates instantly in four forms: bare hexadecimal (eight lowercase digits, zero-padded), the same value with a 0x prefix for source code, the unsigned decimal equivalent, and the number of UTF-8 bytes that were hashed. Use Copy hex to grab the bare hexadecimal result.

The text is encoded as UTF-8 before hashing, so the checksum matches what you would get by saving the text to a UTF-8 file and running a command-line CRC32 tool on it. The well-known reference value — the CRC32 of "The quick brown fox jumps over the lazy dog" — is 414fa339, which you can use to confirm the calculation is behaving as expected.

Everything runs locally in your browser; the text never leaves your device, so it is safe to check internal filenames, identifiers, or content.

What CRC32 is — and is not — good for

CRC32 is a cyclic redundancy check that produces a 32-bit value by treating the input as a long binary number and taking the remainder of a polynomial division. The "IEEE" polynomial used here (0xEDB88320 in its reflected form) is the same one baked into ZIP and gzip archives, PNG image chunks, and Ethernet frame checks. Its job is error detection: store the checksum alongside the data, recompute it later, and if the two differ you know the data was corrupted in transit or on disk.

CRC32 is extremely fast and excellent at catching the kinds of accidental damage that hardware and networks introduce — flipped bits, dropped bytes, burst errors. That is why it is everywhere data is moved or stored. It is also handy as a quick, compact fingerprint for change detection: a build tool can CRC32 a file to decide whether it needs reprocessing, or a cache can use it as a cheap key.

What CRC32 is not is a security mechanism. It is not a cryptographic hash: it is easy to craft a different input with the same checksum, so it cannot detect deliberate tampering and must never be used for passwords, signatures, or integrity against an attacker. With only 32 bits it also collides by chance after enough distinct inputs, so it is unsuitable as a unique identifier at large scale. When you need collision resistance or security, reach for SHA-256 instead; when you just need to catch accidental corruption quickly, CRC32 is the right, lightweight choice.

Common use cases

  • Verifying downloads and archives. Compare a computed CRC32 against the value stored in a ZIP or published alongside a file.
  • Change detection. Fingerprint text or config so a build step or cache can tell when it has actually changed.
  • Debugging data pipelines. Confirm that text survived a round trip through encoding, storage, or transmission unchanged.
  • Matching library output. Reproduce the CRC32 your language's zlib or hashing library returns for a known string.

Frequently asked questions

Which CRC32 variant is this?

The standard IEEE 802.3 polynomial (reflected 0xEDB88320), the same used by ZIP, gzip, PNG, and most zlib-based libraries. The CRC32 of "The quick brown fox jumps over the lazy dog" is 414fa339.

Can I use CRC32 to verify a file has not been tampered with?

No. CRC32 detects accidental corruption, not deliberate tampering — collisions are easy to construct. Use SHA-256 for security-sensitive integrity checks.

Why hex and decimal both?

Different tools report CRC32 differently. Archive utilities usually show hex, while some libraries return an unsigned 32-bit integer, so both forms are provided to match whatever you are comparing against.

How is the text encoded before hashing?

As UTF-8, so the result matches hashing the equivalent UTF-8 file. Non-ASCII characters contribute their multibyte UTF-8 representation.