TTKTheTextKit

CRC32 and Checksum Calculator

Paste text or hex bytes and get the CRC-32 checksum straight away, along with CRC-32C, three common CRC-16 variants, CRC-8 and Adler-32 in one table. Each result is shown in hex and decimal, and a check against the published test value confirms the algorithms are right. Everything runs in your browser.

9 bytes (line breaks count as one byte each, as typed)

CRC-32 (hex)
CBF43926
ZIP, PNG, gzip, Ethernet
CRC-32 (decimal)
3421780262

All algorithms

AlgorithmHexDecimal
CRC-32
ZIP, PNG, gzip and Ethernet. Also called CRC-32/ISO-HDLC.
CBF439263421780262
CRC-32C
Castagnoli. Used by iSCSI, ext4 and many storage systems.
E30692833808858755
CRC-16/ARC
The original "CRC-16".
BB3D47933
CRC-16/CCITT-FALSE
Also called CRC-16/IBM-3740.
29B110673
CRC-16/KERMIT
Often wrongly called CCITT.
21898585
CRC-16/MODBUS
Used by Modbus industrial links.
4B3719255
CRC-8/SMBUS
A short check byte for small packets.
F4244
Adler-32
zlib. Fast, but weak on short data.
091E01DE152961502

Check: the nine characters 123456789 give CRC-32 CBF43926, CRC-32C E3069283 and Adler-32 091E01DE, the published check values.

A checksum is a short number worked out from data, so that a changed file or message gives a different number. CRCs catch accidental damage, such as a flipped bit in a download or a bad cable, and Adler-32 is a faster, weaker cousin. They are not secure: someone can change data and fix the checksum to match, so for tamper protection use a cryptographic hash such as SHA-256. Everything is worked out in your browser and nothing is uploaded.

Related Tools

[5 suggestions]

About the CRC32 and Checksum Calculator

A checksum is a short number calculated from data, so that damaged or changed data gives a different number. A cyclic redundancy check, or CRC, treats the data as a long binary number and divides it by a fixed polynomial, keeping the remainder. Each CRC is defined by its width, its polynomial, its starting value, whether bits are reflected and a final XOR, and different combinations give different answers for the same data, which is why "CRC-16" alone is ambiguous. The catalogue check value for each model is its result for the nine characters 123456789: CRC-32 gives CBF43926, CRC-32C gives E3069283, CRC-16/ARC gives BB3D and CRC-8/SMBUS gives F4. CRC-32 is used by ZIP, PNG, gzip and Ethernet, and CRC-32C by iSCSI and many storage systems. Adler-32 is the checksum at the end of a zlib stream. It keeps two running sums modulo 65521 and is faster than a CRC but weaker, especially on short data: the text Wikipedia gives 11E60398. Text is converted to UTF-8 bytes before the checksum is taken, so accented letters and emoji count as several bytes, and you can switch to hex input to checksum raw bytes. None of these are secure hashes. They are built to catch accidental damage, and anyone can change data and adjust it to keep the same checksum, so use SHA-256 or another cryptographic hash when tampering matters.

What is a CRC32 checksum?▾

CRC-32 is a 32 bit number worked out from data using polynomial division. Files and messages with different content almost always get different values, so it is used to detect corruption in ZIP files, PNG images, gzip and Ethernet.

What is the CRC32 of 123456789?▾

It is CBF43926 in hex, which is 3421780262 in decimal. This is the standard check value used to test a CRC implementation.

What is the difference between CRC32 and CRC32C?▾

They use different polynomials. CRC-32 is the ZIP and Ethernet version, and CRC-32C, from Castagnoli, is used by iSCSI and many storage systems. They give different results for the same data.

Is a CRC or Adler-32 checksum secure?▾

No. They detect accidental changes only. Someone can alter data and adjust it so the checksum still matches, so use a cryptographic hash such as SHA-256 to protect against tampering.

Is my data uploaded?▾

No. The calculation runs in your browser and nothing you enter is sent anywhere.