Algorithms

xxHash

XXH64 or XXH32 with an optional seed. For hash tables and bloom filters and dedup and nothing secret
IDxxhash37 / 46xxHash · 64-bit
Hash / Non-cryptographic

xxHash

XXH64 or XXH32, for hash tables and nothing secret.

Digest
64-bit · 8 bytes
HMAC
no key mode
Security
NOT for security: fast hash for hash tables
Family
1 in xxHash
5 options, 0 required

Sample

hex
45ab6734b21e6968
base64
RatnNLIeaWg=

Options

encodingstring
default hex
Output encoding: hex, base64, base64url, binary
bitsnumber
default 64
64 for XXH64, 32 for XXH32, the one lz4 frames use
seednumber
default 0
Seed value for xxHash
roundsnumber
default 1
How many times to hash, each round hashing the previous digest
chainstring
default bytes
What each round after the first hashes: bytes of the digest, or its lowercase hex

Access

Createcreate("xxhash")
CLIhashes xxhash 'hello world'
Tryplayground with the sample above

xxHash, built for speed and good distribution in hash tables, bloom filters and dedup. Anyone can find collisions on purpose. XXH64 by default, XXH32 with bits: 32, the one lz4 frames check their blocks with. zstd keeps the low four bytes of XXH64 for its own check.

ts
create("xxhash").hash("").digest; // "ef46db3751d8e999"
create("xxhash").hash("abc").digest; // "44bc2cf5ad770999"
create("xxhash").hash("abc", { seed: 1 }).digest; // "bea9ca8199328908"
create("xxhash").hash("abc", { bits: 32 }).digest; // "32d153ff"

The seed is an unsigned integer as wide as bits. Past Number.MAX_SAFE_INTEGER, pass it as a bigint or a decimal string, so "18446744073709551615" works and nothing gets rounded. Checked against the reference C library on hundreds of inputs, after an earlier version of this package got XXH64 quietly wrong. That's the regression test's reason to exist.