AnyHash
Skip to content

Checksum Generator

CRC-32, xxHash32, xxHash64, MurmurHash3, and FNV-1a — five lightning-fast, non-cryptographic fingerprints for files and text, computed entirely in your browser.

Not for security. These checksums detect accidental corruption and power hash tables and deduplication — they are not collision-resistant and must never be used for passwords or signatures. For that, use SHA-256 or BLAKE3.

Or drop a large file to checksum it at multi-GB/s speed

Drag & drop · up to 64 MB

Checksum

 

Type or paste input to see its checksum instantly.

Code snippets

Generate Checksum in your language

import { createHash } from "node:crypto";
import xxhash from "xxhash-wasm";

// CRC-32 (zlib) — built in:
console.log(createHash("crc32").update("hello world").digest("hex"));

// MurmurHash3 + FNV-1a are not in Node's crypto; use a package.
// xxHash via xxhash-wasm:
const { h32, h64 } = await xxhash();
console.log(h32("hello world", 0).toString(16));
console.log(h64("hello world", 0n).toString(16));

Only CRC-32 is built into Node.js, Python, and OpenSSL. xxHash, MurmurHash3, and FNV-1a need small packages — all compute in microseconds even on multi-MB inputs.

Why five fingerprints?

"Checksum" covers a whole family of functions that trade away cryptographic guarantees for sheer speed. Nothing here is collision-resistant, and none of them hide your data — but each is the right tool for a specific job, from corrupt-file detection to hash-table spreading.

Cryptographic hashes like SHA-256 coast at hundreds of MB/s; xxHash and CRC-32 software implementations reach many GB/s, which is why file systems and databases fingerprint content with them.

At a glance

  • CRC-32 — the classic; lives inside ZIP, PNG, GZIP (IEEE polynomial)
  • xxHash32 / xxHash64 — fastest family; dedupe engines, caches
  • MurmurHash3 — the hash-table / bloom-filter workhorse
  • FNV-1a — tiny, embeddable; dictionary & string-table hashing

Algorithm guide

Checksums explained

What is a checksum?

A checksum is a fixed-size fingerprint of data that is optimized for fast computation and avalanche diffusion — not for adversarial resistance. Good checksums flip roughly half their output bits when any input byte changes, so they spot accidental corruption instantly, but an attacker who controls the input can trivially engineer collisions.

CRC-32

Cyclic Redundancy Check 32 processes each byte through polynomial division (the ubiquitous IEEE 802.3 / zlib polynomial 0xEDB88320). It is famously easy to build into hardware, which is why it dominated storage and file formats; software performance is only middling today. CRC-32 outputs 8 hex characters, and its cryptanalytic lore matters here: a 2005 paper showed how to forge arbitrary messages under CRC-32, misleading naive tools that mistake it for a hash.

xxHash32 & xxHash64

xxHash is a 2012 design by Yann Collet (of Zstandard) built around wide 64-bit arithmetic, the same math that made modern PRNGs fast. Its software implementations sustain multiple GB/s — the fastest widely used checksum family here. xxHash64 is the default fingerprint in deduplication engines, content-addressed stores, and cache keys; xxHash32 fills the 32-bit niche on embedded targets.

MurmurHash3

MurmurHash3 (Austin Appleby, 2008) is the archetypal hash-table hash: extremely fast on byte-at-a-time inputs and exceptionally good at spreading similar keys across table buckets. It is the default scatterer behind Cassandra, Redis Cluster slots, and countless bloom filters. This tool computes the x86_32 variant (8 hex characters), the most deployed form.

FNV-1a

Fowler–Noll–Vo 1a is the smallest respectable checksum in use: a prime-multiply–XOR loop with no table, no state beyond a 64-bit accumulator, perfect for microcontrollers and embedded engines. FNV-1a's distribution is weaker than MurmurHash on adversarial keys, but it is trivially parameterized and fast on short strings, which keeps it popular in protocol dictionaries and status-code lookups.

Why none are secure

  • Non-cryptographic by design — avalanche is good but not adversarial; controlled inputs collide easily.
  • CRC-32 is outright forgeable — it is a linear function, so an attacker can patch bytes and adjust the checksum to match any forgery.
  • Short outputs — 32-bit checksums invite accidental-name collisions in big corpora (the birthday bound bites around ~77k items for 32 bits).

Checksums shape hash-table routing and catch torn writes — never identity, authenticity, or passwords.

How this tool works

CRC-32 and xxHash run through hash-wasm's WebAssembly builds; MurmurHash3 and FNV-1a use fast hand-written JavaScript (hash-wasm has no murmurs), with FNV-1a computed in 64-bit big-int arithmetic. All five run entirely in your browser — text or file bytes are decoded and hashed locally, never uploaded. The output length tells you the variant: 8 hex = 32-bit, 16 hex = 64-bit.

Worked examples you can verify right now

InputCRC-32xxHash64 (seed 0)FNV-1a 64-bit
hello world0d4a118545ab6734b21e6968779a65e7023cd2e7
anyhash866dc91f67399c7334731563580cedb7ae153659
(empty string)00000000ef46db3751d8e999cbf29ce484222325

These values are generated by this very tool — flip one character in the input and every row changes beyond recognition. Select CRC-32 for an 8-hex result, or xxHash64 / FNV-1a for a 16-hex result.

Frequently asked questions

Are CRC32, xxHash, MurmurHash, and FNV-1a secure?

No — they are intentionally fast, non-cryptographic fingerprints designed for integrity, deduplication, and data structures, not security. CRC-32 was broken as a checksum with trivial collision attacks in 2005, and xxHash/FNV/Murmur are not collision-resistant. Never use them for passwords, signatures, or authenticity.

What is the difference between CRC-32 and xxHash?

CRC-32 is a simple polynomial division over bits, easy to implement in hardware but slow in software; xxHash uses a wider 64-bit arithmetic design and is dramatically faster on modern CPUs. CRC remains the default in zlib, PNG, and ZIP; xxHash wins on raw speed.

Why would I use these if they're not cryptographic?

They shine exactly where cryptographic hashes hurt: high-throughput data pipelines, hash tables and bloom filters (MurmurHash), deduplication by content fingerprint (xxHash), or quick integrity checks against accidental corruption (CRC-32 in file formats).

Other hash tools