Info & Theory
A cryptographic hash maps any input to a fixed-length output that behaves like a random fingerprint. Two properties make it useful: the avalanche effect and resistance to collisions.
The avalanche effect
A small change to the input — even a single bit — should flip
about half of the output bits. Outputs for similar
inputs look completely unrelated, so you cannot reverse-engineer
the input or nudge it toward a target hash.
The birthday bound
With a b-bit hash there are
B = 2ᵇ possible outputs. A collision (two inputs
with the same hash) becomes likely much sooner than B — around
√B samples. The probability is approximately
1 − e^(−n²⁄2B) for n samples.
Why √B, not B
Each new sample can collide with every earlier one, so the
number of pairs grows like n². That quadratic
growth is why a room of just 23 people likely shares a birthday,
and why a 256-bit hash needs ~2¹²⁸ work to break by brute
collision — still astronomically hard.
About this simulation
For speed the hash here is a small deterministic mixing function (FNV-1a plus xorshift), not SHA-256. It still exhibits the avalanche effect and the birthday bound, which are properties of any good hash.
Frequently asked questions
What is a cryptographic hash function?
It is a function that maps any input to a fixed-length output that behaves like a random fingerprint. The same input always gives the same output, but the output reveals nothing useful about the input.
What is the avalanche effect?
The avalanche effect means a tiny change to the input — even one bit — flips about half of the output bits. It makes similar inputs produce completely unrelated hashes.
What is a hash collision?
A collision is when two different inputs produce the same hash output. A good hash makes finding one computationally infeasible.
What is the birthday paradox in hashing?
It is the surprising result that collisions become likely after only about the square root of the number of possible outputs, far sooner than intuition suggests.
Why are collisions likelier than expected?
Because each new sample can collide with every previous one, the number of pairs grows quadratically. So the chance of any collision rises much faster than the chance of hitting one specific value.
How many samples cause a likely collision?
For a b-bit hash with B = 2 to the power b outputs, a collision becomes likely around the square root of B samples. The probability is roughly 1 minus e to the power of minus n squared over 2B.
Why should about half the bits change?
If each output bit were an independent fair coin, flipping any input would change each output bit with probability one half, so on average half of them flip. That is the ideal a strong hash imitates.
Is the hash in this simulation real SHA-256?
No. For speed it uses a small deterministic FNV-1a plus xorshift mixing function. It still shows the avalanche effect and birthday bound, which are properties of any good hash.
Why use a fixed-length output?
A fixed-length digest lets you compare, store and index data of any size in constant space, and it is what makes signatures, integrity checks and proofs efficient.
How big does a hash need to be to resist collisions?
Because of the birthday bound, a hash needs about twice as many bits as the security level you want. A 256-bit hash gives roughly 128 bits of collision resistance.
About this simulation
This simulation demonstrates two core properties of a cryptographic hash using a small, fast FNV-1a hash (a non-cryptographic mixing algorithm named after Fowler, Noll and Vo) finished with an xorshift step, producing a 32-bit digest (a fixed-length fingerprint of the input). In Avalanche mode, your text is hashed live and drawn as a bit grid; flipping one input bit recomputes the hash and highlights every output bit that changed — the avalanche effect. In Birthday mode, random samples are hashed into a b-bit space of B = 2b buckets and checked for collisions, plotting the observed collision rate against the theoretical birthday bound 1 − e−n²/2B.
🔬 What it shows
A 32-bit hash rendered as a 4×8 grid of 0/1 cells for Avalanche mode, with any bit that flipped between input A and input B picked out in red; and, for Birthday mode, a live plot of collision probability versus number of samples drawn, comparing an amber theoretical curve to a green observed data point.
🎮 How to use it
Switch between the Avalanche and Birthday views with the two mode buttons. In Avalanche, type any text into the input box and press "Flip one bit" to mutate one random character by a single bit, or "Reset" to return to "hello world". In Birthday, drag the "Hash bits b" slider (4–16) to resize the bucket space and "Samples drawn" (1–120) to change how many values are hashed per trial, then press "Run 1 trial" or "Run 200 trials" to accumulate an observed collision rate.
💡 Did you know?
The birthday bound is why real hash functions need roughly double the bit-length of their intended security level: SHA-256 produces a 256-bit digest, but because collisions become likely after only about √B attempts, its actual collision resistance is closer to 128 bits — the same square-root effect this simulation's slider lets you see directly.
Frequently asked questions
What algorithm computes the hash in this simulation?
It uses FNV-1a, a fast non-cryptographic hash: it starts from a fixed offset basis, then for each input character XORs the running value with the character code and multiplies by a fixed prime (0x01000193). The result is then passed through an xorshift finishing step (three XOR-shift operations) to spread bits more thoroughly, producing a 32-bit output. It is not SHA-256, but it still exhibits the same avalanche and collision behaviour that real cryptographic hashes are designed around.
Why does flipping one bit change so many output bits?
Because of how FNV-1a's multiply-and-XOR chain mixes each input byte through every later step, and because the xorshift finisher spreads any single-bit difference across the whole 32-bit word, changing one input bit cascades into roughly half of the 32 output bits flipping, on average. That property is the avalanche effect, and it is exactly what the red highlighted cells in Avalanche mode are showing you bit by bit.
What do the "Hash bits" and "Samples drawn" sliders control in Birthday mode?
"Hash bits b" sets the width of the hash space: with b bits there are B = 2b possible output buckets (from 16 buckets at b=4 up to 65,536 at b=16). "Samples drawn" sets how many random values are hashed into that space in a single trial before the simulation checks whether any two landed in the same bucket. Both sliders reset the running trial statistics so the observed rate always reflects the current settings.
Why doesn't the observed collision rate exactly match the predicted curve?
The amber curve plots the closed-form birthday bound 1 − e−n²/2B, an approximation that is exact only in the limit of many trials. The green point is a real empirical average over however many trials you have actually run (shown as "Trials run" in the stats panel); with only a handful of trials, random chance means the observed fraction can sit noticeably above or below the theoretical line. Press "Run 200 trials" repeatedly to shrink that gap.
Is this simulation's hash function secure enough for real cryptography?
No — FNV-1a plus an xorshift finisher is fast and shows the right statistical behaviour for teaching, but it lacks the cryptographic design (fixed-point rounds, key schedules, proven diffusion bounds) that make functions like SHA-256 resistant to deliberate attack. Real systems must use a vetted cryptographic hash; this simulation only borrows the same two properties — avalanche and the birthday bound — to make them visible and interactive.