How to use the non-cryptographic hash calculator
- Choose whether your input is text or hex bytes.
- Type or paste the input. Text is turned into UTF-8 bytes.
- Set a seed for MurmurHash3 and xxHash32, and the number of buckets to place the hash into.
- Read the table with every hash in hex and decimal, and the bucket it chooses.
Formula
FNV-1: h = h x prime, then h = h xor byte. FNV-1a: h = h xor byte, then h = h x prime. Offset basis 0x811c9dc5 and prime 0x01000193 for 32 bits
djb2: h = h x 33 + byte, starting at 5381. sdbm: h = byte + (h << 6) + (h << 16) - h
Jenkins one-at-a-time: add the byte, add h << 10, xor h >> 6, and finish with three more mixing steps
bucket = hash mod number of buckets
MurmurHash3 and xxHash32 read four bytes at a time with several multiplications and rotations. Every 32-bit step is taken modulo 2^32.
The text foobar
FNV-1a with 32 bits gives bf9cf968 and with 64 bits 85944171f73967e8. FNV-1 gives 31f0b262. With seed 0, MurmurHash3 gives a4c4d4bd and xxHash32 gives eda34aaf. Jenkins one-at-a-time gives f952fde7, djb2 gives fde460be and sdbm gives a6437b0d.
With 16 buckets, the FNV-1 value 0x31f0b262 falls in bucket 2. The empty text hashes to 811c9dc5 under FNV-1a and to 00000000 under MurmurHash3 with seed 0. The 4 bytes de ad be ef give a different set of values from the text deadbeef, because bytes and text are not the same thing.
What these hashes are for
Hash tables, caches, sharding, deduplication and bloom filters need fast hashes that spread keys evenly. They do not need to resist an attacker. That is why these functions are short and quick, and also why they are a poor choice for passwords or signatures. For a secure hash, use the Hash Generator and File Checksum.
To see how hashes place keys on servers, try the Consistent Hash Ring Simulator. The Bloom Filter Calculator sizes a filter that uses several hashes, and the CRC32 Checksum Calculator is the right tool for catching accidental damage to a file. Check characters on identifiers are in the ISO 7064 Check Character Calculator.
Why the same text gives different values in different programs
Hashes work on bytes, so the text encoding matters. This tool uses UTF-8. A program that hashes UTF-16 characters, or that treats text as signed bytes, will give another value. Seeds, the width of the result and whether the bucket is taken from the low or high bits also differ between libraries.
Assumptions and limits
- The input is read as UTF-8 text or as the hex bytes you give.
- Each result is shown as an unsigned number. The 64-bit hash uses exact integer arithmetic.
- The seed applies to MurmurHash3 (x86, 32-bit) and xxHash32 only.
- Up to 100,000 characters are read, and nothing is uploaded.
Frequently asked questions
Is any of these safe for passwords?
No. They are built for speed, and a fast hash is the wrong tool for passwords. Use a slow password hashing function that is designed for the job.
Why do two hashes of the empty input differ?
Each function begins from its own starting value. FNV-1a starts at 0x811c9dc5, djb2 at 5381, and MurmurHash3 with seed 0 gives zero for no input.
Which one should I pick for a hash table?
Murmur3 and xxHash32 spread keys well and are common in libraries. FNV-1a is the simplest and works well for short keys. Test with your own data, since the best choice depends on the keys.
What is a bucket?
A slot in a table. Taking the hash modulo the number of buckets picks the slot for a key. A good hash makes every bucket about equally full.