djb2 Hash Calculator

djb2 is a classic string hash by Daniel J. Bernstein, famous for being tiny yet effective. It appears in countless C codebases and tutorials as the go-to example of a fast, simple string hash. This calculator computes both the standard add variant and the xor variant (sometimes called djb2a) in your browser, showing results in both decimal and hex.

How it works

djb2 keeps a single 32-bit accumulator, stepping through the input one byte at a time:

1. Initialise hash = 5381.
2. For each byte c: hash = hash * 33 + c. Most C implementations write this as hash = ((hash << 5) + hash) + c — identical arithmetic, slightly faster on older hardware without a barrel shifter.
3. Return the 32-bit accumulator after processing the last byte.

The xor variant (djb2a) is identical except the addition in step 2 is replaced with XOR: hash = hash * 33 ^ c. The two variants distribute equally well in practice; xor mixing is occasionally preferred for bit patterns that differ only in adjacent bytes.

Reference values

The empty string always returns 5381 for both variants because no bytes are processed. You can verify the tool against the hello test case above.

Why 5381 and 33?

The constants are empirical, chosen by Bernstein through experimentation on typical English-text inputs. The magic of 33 (equal to 2^5 + 1) is that it is efficiently computable as a shift and add, and it distributes consecutive ASCII characters into non-adjacent hash buckets better than 31 or 32. The seed 5381 is a prime that avoids the degenerate all-zero initial state while remaining small enough to fit in a few machine words even on early compilers.

When to use djb2 — and when not to

Good fits:

• Hash table keys for strings in language runtimes and configuration parsers. Erlang, Tcl, and many scripting-language implementations have used djb2 or close relatives.
• Quick fingerprints for non-security deduplication — for example, tagging log lines or detecting duplicate enum strings at compile time.
• Teaching and reference — the algorithm is short enough to memorise and reproduce from scratch, making it useful for explaining hash function concepts.

Poor fits:

• Security-sensitive hashing — djb2 has no collision resistance against adversaries. Deliberate collisions are trivial to produce, enabling hash-flooding denial-of-service attacks on hash tables. For hash maps exposed to untrusted input, use a keyed hash like SipHash.
• Files or large binary data — djb2 processes one byte at a time with no vectorisation path. For bulk data, MurmurHash3 or xxHash are far faster.
• Password storage — never use any fast hash for passwords. Use Argon2, bcrypt, or scrypt.

Comparison with similar non-cryptographic hashes

For new code where performance matters, prefer MurmurHash3 or xxHash. Use djb2 when you need interoperability with existing systems or the smallest possible implementation footprint.