Checksum Generator

Compute CRC-32, Adler-32 and FNV-1a checksums in hexadecimal and decimal.

  • Runs locally in your browser
  • No upload required

Try it

Algorithm
CRC32
Checksum (hex)
cbf43926
Checksum (decimal)
3421780262
Width
32 bits
Input size
9 UTF-8 byte(s)

Supported formats

Input
text, select
Output
text

Privacy

Runs entirely in your browser. Your input is never uploaded, stored, or sent to a third party.

Processing
In your browser
Privacy level
Browser only

CRC32 checksum of 9 UTF-8 byte(s): cbf43926 (3421780262).

How it works

  • Encoded the input as 9 UTF-8 byte(s).
  • Applied the crc32 update rule byte by byte.
  • Formatted the 32-bit result as cbf43926 and 3421780262.
textSelect to copy
CRC32(message) = 0xcbf43926
  • A checksum detects accidental corruption; it does not prove authenticity and is not tamper-proof.

Methodology

  1. Encode the input as UTF-8 bytes so the checksum is locale-independent.
  2. CRC-32 uses the reflected IEEE polynomial 0xEDB88320 with an initial value of all ones and a final one's-complement (the zlib/RFC 1950 form).
  3. Adler-32 accumulates two running sums modulo the largest prime below 65536 (65521) and combines them into a 32-bit value.
  4. FNV-1a starts from the 32-bit offset basis 0x811c9dc5 and, per byte, XORs then multiplies by the prime 0x01000193.

Usage

  1. Type or paste the text to checksum.
  2. Choose CRC-32, Adler-32 or FNV-1a.
  3. Read the checksum in hexadecimal and unsigned decimal.

Examples

These are examples, not current values: they use fixed inputs, while the interactive tool computes live results in your browser.

CRC-32 of "123456789"

jsonSelect to copy
{
  "text": "123456789",
  "algorithm": "crc32"
}

Adler-32 of "Wikipedia"

jsonSelect to copy
{
  "text": "Wikipedia",
  "algorithm": "adler32"
}

FNV-1a of the empty string

jsonSelect to copy
{
  "text": "",
  "algorithm": "fnv1a"
}

Limitations

Checksum versus digest

A checksum is designed around speed and accidental-error detection, while a cryptographic digest is designed around collision resistance. CRC-32 catches the burst errors that matter on a network link or a disk; it is not a security primitive and is trivially forgeable.

When the question is 'did this data change by accident?', a checksum is the right tool. When the question is 'did someone change this data?', use SHA-256 or HMAC.

Where these checksums are used

CRC-32 is the checksum inside zlib, gzip, PNG and Ethernet frames. Adler-32 is zlib's faster alternative, used in the zlib stream header. FNV-1a is widely used in hash tables, bloom filters and content-addressing schemes where speed matters more than collision resistance.

Frequently asked questions

Which checksum should I use?
CRC-32 is the common choice for detecting transmission or storage corruption and is what zip, gzip and Ethernet use. Adler-32 is faster but weaker; FNV-1a is a simple, fast non-cryptographic hash good for hash tables.
Can a checksum replace SHA-256?
No. A checksum catches accidental damage. It offers no protection against a malicious change, so it must never be used to verify signatures, downloads from an untrusted source, or passwords.
Why does FNV-1a have a '1a' variant?
FNV-1a multiplies before XORing each byte (the original FNV-1 XORs first). The 1a order has better avalanche behavior and is the variant used here.

Sources

  1. RFC 1950: ZLIB Compressed Data Format Specification (CRC-32 and Adler-32) — IETF
  2. Fowler–Noll–Vo hash function (FNV-1a) — Fowler–Noll–Vo
  3. RFC 1321: The MD5 Message-Digest Algorithm — IETF