A hash table finds a key in about one step by computing where it should be stored. This visualizer shows each step: the hash function is worked out with your key (key mod m for numbers, a polynomial hash for words), the key goes to that bucket, and when two keys land in the same bucket you see how the collision is handled.
Switch between separate chaining, where each bucket holds a linked list of keys, and linear probing, where a colliding key moves to the next free slot. Delete a key under linear probing to see why it leaves a “deleted” marker (a tombstone) instead of an empty slot. The load factor shows how full the table is.
How to use the Hash Table Visualizer tool
- Choose Separate chaining or Linear probing, and a table size m.
- Type a key (a number or a word) and press Insert, Search or Delete.
- Read the hash calculation at the top, then follow the highlighted slot and the probe or chain walk.
- Insert a key that collides (the hint suggests one) and compare how the two methods handle it.
Why use ToolOrca Hash Table Visualizer
- Hash function calculation shown for every key
- Separate chaining and linear probing modes
- Collision handling animated step by step
- Tombstones for deletes in open addressing
- Load factor and probe counter
- Number and string keys
- Code in C++, Java, Python and JavaScript
How a hash table works
A hash table is an array of m buckets plus a hash function that turns a key into a bucket number. For integers a simple choice is h(k) = k mod m; for strings a common one is h = (h × 31 + character code) mod m over every character. A prime table size spreads keys more evenly. To find a key you hash it and look only in that one bucket, which is why the average lookup is O(1).
Two different keys can hash to the same bucket: a collision. With m buckets, collisions are unavoidable once you store more than a few keys (the birthday paradox), so every hash table needs a collision strategy.
Separate chaining vs linear probing
Separate chaining keeps a small linked list in each bucket. Colliding keys are appended to the list, and a search walks only that list. It works even when the table holds more keys than buckets, and deletes are simple. Java’s HashMap and C++ unordered_map use chaining.
Linear probing (a form of open addressing) stores one key per slot. If the home slot is taken, try the next slot, (i + 1) mod m, until a free one is found. Search follows the same path and stops at an empty slot. Deleting must leave a tombstone, otherwise later searches would stop too early. It is cache friendly but suffers from clustering as the table fills, so it is resized well before it is full. Python’s dict uses open addressing.
Load factor and resizing
The load factor is n / m, the number of keys divided by the number of buckets. As it grows, chains get longer and probe sequences get slower. Real hash tables resize (typically doubling and rehashing every key) when the load factor passes about 0.75 for chaining or 0.5 to 0.7 for probing, which keeps operations O(1) on average.
Every visualizer on this site runs in your browser with the same controls: Play, Pause, Step forward, Step back and a speed slider. You can also drag the position slider to jump to any step, or focus the drawing and use the Space bar and arrow keys.
Frequently asked questions
What is a hash collision?
Two different keys that the hash function maps to the same bucket. For example, with m = 11 the keys 3 and 14 both give 3 mod 11 = 14 mod 11 = 3.
Which is better, chaining or linear probing?
Chaining is simpler and handles high load factors gracefully. Linear probing uses less memory and is faster thanks to the CPU cache, as long as the table is kept less than about 70% full.
Why does linear probing need tombstones?
A search stops when it reaches an empty slot. If a delete simply emptied a slot, keys stored further along the same probe path could no longer be found. A tombstone says “keep looking”.
What is the worst-case time of a hash table?
O(n), when all keys collide into one bucket or one long cluster. A good hash function and resizing keep the average at O(1).
Why should the table size be a prime number?
With k mod m, keys that share a common factor with m (for example all even keys with an even m) would crowd into a few buckets. A prime m spreads such patterns more evenly.