Non-cryptographic
FNV-1a
The Fowler-Noll-Vo hash family (1991) is a tiny multiply-XOR mixer that fits in a few lines of code. FNV-1a, the “XOR-then-multiply” variant, distributes input bits noticeably better than the original FNV-1 and is the de facto choice for the family today.
The whole algorithm, in one fragment
hash = FNV_OFFSET_BASIS
for each byte b in input:
hash = hash XOR b
hash = hash * FNV_PRIME # modulo 2^n, where n = 32 or 64At a glance
| Output | 32 or 64 bits (1024-bit variants exist but rarely used) |
|---|---|
| Internal state | 1 integer of output size |
| Throughput | ~1–3 GiB/s (single-byte loops; can be SIMD-vectorized) |
| Year | 1991 (original); FNV-1a variant ~1996 |
| Status | Non-cryptographic; trivially collidable but fine for hash tables |
Constants
| Variant | Offset basis | Prime |
|---|---|---|
| FNV-1a 32 | 0x811c9dc5 | 0x01000193 |
| FNV-1a 64 | 0xcbf29ce484222325 | 0x00000100000001b3 |
Where it shows up
- Language internals , Python (CPython’s dict pre-3.4), Rust’s
FxHashderivative. - Embedded firmware , sub-200-byte assembly hash for hash tables / Bloom filters.
- Stub identifiers , quick uniqueness keys in build tools, code generators.
- Bloom-filter back-ends , FNV is the “simplest correct choice” default in many libraries.
Limitations
- Avalanche is decent but not great; deliberate collisions are easy to construct.
- Pure byte-loop; harder to SIMD-vectorize than xxHash3.
- No seed (unless you treat the offset basis as one), so vulnerable to hash flooding when used as a key for hash tables.
For hot paths with adversarial inputs, prefer SipHash. For sheer throughput, prefer xxHash3.