Hash Table Collisions Screensaver
The Hash Table Collisions screensaver inserts real random keys into a live hash table, showing them hash into buckets and chain when real collisions occur. It is free, runs in your browser, and ESC exits.
Live preview
Press ESC to leave fullscreen. Settings are saved in your browser only.
How the Hash Table Collisions screensaver works
The saver generates a real random key, runs it through a real hash function, and drops it into the resulting bucket.
When two keys genuinely hash to the same bucket, the real table chains them together in a small list rather than overwriting either one.
A live load-factor readout tracks the real ratio of stored keys to buckets, exactly the number that governs real hash table performance.
Once the table fills to a set load factor, it holds briefly, then clears and a fresh hash table begins filling from empty.
Collisions are inevitable, so tables plan for them
A hash table stores items by passing each key through a hash function that turns it into a number, then reducing that number to a bucket index. If the function spreads keys evenly, lookup takes roughly constant time however many items are stored, which is why hash tables sit behind dictionaries, sets and caches in many programming languages. Python documents its dictionaries as resizable hash tables.
Collisions, where two different keys land in the same bucket, cannot be avoided. The pigeonhole principle guarantees them once there are more keys than buckets, and the birthday problem shows they arrive sooner than intuition suggests: with 23 people the chance of a shared birthday is already about 50.7%, and the same mathematics applies to hash values. What matters is how the table responds. Chaining, as shown here, keeps a small list in each bucket, while open addressing probes for another free slot in the table itself.
The key figure is the load factor, the number of stored items divided by the number of buckets. As it rises, chains grow and lookups slow down, so real tables resize, commonly growing the bucket count and re-inserting everything, to keep it below a threshold.
A worked example
Two unrelated random keys land in the same bucket purely by chance, and the real table visibly chains the second one behind the first rather than losing either key.
Settings & tips
- Accent recolours the bucket currently receiving a key.
- This is a real hash function and real separate-chaining collision handling.
- The table clears and refills automatically once it reaches full load.
Frequently asked questions
- Is this a real hash table?
- Yes — a real hash function and real separate-chaining collision resolution, exactly as used in real hash map implementations.
- Why do collisions happen?
- With real random keys and a finite number of buckets, two different keys genuinely land in the same bucket now and then — this is expected, not a bug.
- Is a key needed?
- No — it is a pure local computation.
- Is it free?
- Yes — free, no download, in your browser.
- What is the birthday paradox?
- It is the surprising fact that collisions occur much earlier than expected: among only 23 people there is about a 50.7% chance two share a birthday, and the same maths governs hash collisions.
- What is the difference between chaining and open addressing?
- Chaining stores colliding items in a list inside the bucket, while open addressing places them in another empty slot found by a probing sequence.
- Why do hash tables resize?
- A higher load factor means longer chains or more probing. Growing the table and redistributing the keys restores short lookups, at the cost of an occasional expensive rebuild.