What this shows
A real hash table with separate chaining — insert and look up keys and watch the actual hash computation happen character by character, land on a bucket, and either slot in cleanly or collide with something already there. This is the mechanism behind the "O(1) average" you'll see quoted for Map and Set everywhere on this site, made concrete instead of taken on faith.
How the hash is computed
Each key is hashed with a polynomial rolling hash — the same multiplier (31) used by String.hashCode in Java and many textbook examples: starting from 0, every character folds in as hash = (hash × 31 + charCode) mod 1,000,003. The modulus keeps the running value bounded and readable instead of growing without limit for longer keys. The final hash is then reduced to a bucket index with hash mod numBuckets — the step where a huge space of possible hash values gets folded down onto a handful of actual buckets, which is also exactly where collisions come from.
Why collisions are inevitable, not a bug
With more possible keys than buckets, two different keys hashing to the same bucket isn't a flaw in the hash function — it's guaranteed by the pigeonhole principle the moment the table holds more entries than buckets exist. This implementation handles it with separate chaining: every bucket holds a small list, and a collision just means appending to that list instead of overwriting anything. Drag the bucket count down to 4 and insert a handful of keys to see collisions happen quickly and reliably — a real demonstration of why hash table performance depends on keeping enough buckets relative to the number of entries.
What load factor has to do with O(1)
Load factor is entries ÷ buckets — the average chain length across the whole table. A lookup has to walk the full chain in its bucket in the worst case, so a low load factor is what actually makes lookups close to O(1) in practice; a hash table with far more entries than buckets degrades toward O(n), since every bucket ends up with a long chain to scan. Real hash table implementations resize (allocate more buckets and rehash everything) once load factor crosses a threshold specifically to keep this from happening — this visualizer doesn't auto-resize, so you can watch what growing load factor does to chain length directly.
FAQ
Why does inserting an existing key not create a duplicate?
Real hash maps treat insert as "set" — inserting a key that's already present updates its value instead of appending a second entry for the same key. Try inserting one of the seeded keys (array, stack, queue, tree) with a new value to see this directly.
Is this the only way to handle collisions?
No — separate chaining (used here) is the most common and the easiest to visualize, but open addressing (probing for the next free slot instead of chaining) is a real alternative with its own tradeoffs, not covered by this tool.
How does this relate to Big O?
See Time Complexity Interview Guide for the data structure operation cheat sheet this tool makes concrete, and When O(n²) Becomes a Problem for a real example of a nested-loop function rewritten around exactly this data structure.
Is anything I type here sent anywhere?
No — every operation runs entirely in your browser. Nothing here is ever sent to a server.