Hash Table Visualizer — Free HTML CSS JS Snippet

A hash table is usually presented as a magic O(1) box — you put a key in, you get a value out — and that magic is exactly what makes collisions so confusing the first time a learner hits one. This snippet opens the box: eight visible buckets, a hash function whose arithmetic plays out on screen character by character, and a separate-chaining collision strategy that visibly appends rather than silently overwrites, so "why did two different keys end up in the same place" has an obvious, watchable answer.

The hash function: sum of char codes, deliberately simple

hashOf(key) sums every character's charCodeAt() value and takes the result modulo BUCKET_COUNT (8). This is intentionally the simplest possible string hash, not a production-grade one (real hash tables use algorithms like FNV-1a or MurmurHash specifically to avoid the weaknesses described below) — the goal here is that a viewer can compute it by hand for a short key and verify the animation is telling the truth, not asking them to trust a black box. animateHash(key) walks the same character-code sum the real hashOf uses, updating a status strip after each character so the running total — and the final % 8 step that folds it down into a valid bucket index — is visible as a process, not just a final answer.

Separate chaining: why collisions never overwrite

Each of the 8 buckets holds a plain JavaScript array (buckets[i]), not a single slot. When insertKey computes a bucket index and finds the bucket's array already has one or more entries with different keys, it does not touch them — it pushes the new { key, value } pair onto the end of that array, and the DOM chain visualization appends a new .ht-entry element with a small arrow prefix showing it as a link in a chain. This is the "separate chaining" collision resolution strategy by name: instead of finding another empty slot elsewhere in the table (the alternative strategy, "open addressing"), every bucket independently becomes its own small linked list of entries, and two keys landing on the same bucket simply means that bucket's chain has two elements instead of one.

Insert first checks for an existing key, not just a free bucket

Before appending, insertKey runs chain.find(e => e.key === key) on the target bucket's chain. If the exact same key already exists there, its value is updated in place (with a green "match" pulse) rather than appended as a duplicate entry — this mirrors how a real hash map's set() behaves: same key always updates, never duplicates, while a different key that happens to hash to the same bucket always appends alongside it as a genuine collision.

Lookup walks the chain and compares keys one at a time

lookupKey re-runs the identical animateHash step to jump straight to the correct bucket — this is the O(1) part, since no other bucket is ever inspected — and then, critically, does not assume the first entry in that bucket is the answer. It iterates the bucket's array from the front, highlighting each entry amber while comparing entry.key === key, and only stops early on an exact match (turning it green) or reports a full miss after exhausting the whole chain. This walk is the part of a hash table's cost that a single "hash and index" step glosses over: a bucket with a long chain means a lookup that still has to compare several keys one by one, even though it started with an O(1) jump to the right bucket.

Load factor: the number that predicts chain length

The footer's live Load factor: items / buckets readout is not decorative — it is the standard metric real hash table implementations use to decide when to resize. A load factor near or above 1 means, on average, every bucket holds roughly one or more chained entries, so lookups start doing real chain-walking work instead of landing on a single-entry bucket; production hash maps (JavaScript's own Map, Java's HashMap, Python's dict) automatically grow their bucket count and re-hash every existing key once the load factor crosses a threshold (commonly around 0.75) specifically to keep chains short and lookups close to O(1) in practice.