CRC-32 Checksum Calculator
NewCompute the standard CRC-32 (zlib/gzip/PNG/Ethernet) checksum of text or a file.
…or drag and drop a file here. Read and hashed entirely in your browser.
—
Decimal: —
This is the standard CRC-32 used by zlib, gzip, PNG, and Ethernet (polynomial 0xEDB88320, reflected, with a final XOR) — the same variant Python's zlib.crc32() and PowerShell's Get-FileHash -Algorithm CRC32-style tools produce. It is a fast error-detection checksum, not a cryptographic hash — it is trivial to forge, so don't use it for security purposes.
Frequently Asked Questions
Which CRC-32 variant does this use?
The IEEE 802.3 / zlib / gzip / PNG variant: polynomial 0xEDB88320 (the reflected form of 0x04C11DB7), initial value 0xFFFFFFFF, input and output reflected, and a final XOR with 0xFFFFFFFF. This is the same result you get from Python's `zlib.crc32()` or the checksum in a gzip/PNG file trailer.
Is CRC-32 the same as a cryptographic hash like SHA-256?
No. CRC-32 is an error-detection checksum designed to catch accidental bit flips (network noise, disk corruption) cheaply — it is trivial to deliberately construct a different input with the same CRC-32, so it must never be used for security, password, or tamper-detection purposes.
Can I hash a file instead of typed text?
Yes — switch to the "File" tab, then choose or drag-and-drop a file. It's read via the File API and checksummed locally.
Why does it show both hex and decimal?
CRC-32 checksums are conventionally written in hex in tools like `gzip -l` or PNG chunk dumps, but some contexts (certain APIs, some legacy database columns) store or compare it as a plain unsigned 32-bit decimal integer — both are shown so you don't have to convert it yourself.
Does whitespace or line-ending style affect the result?
Yes — CRC-32 is computed over the exact bytes you provide, so different line endings (CRLF vs LF) or trailing whitespace produce a different checksum, the same as any other byte-level checksum or hash.