What this shows
A real binary search tree — insert, search, and delete a value and watch every comparison that decides which way the walk goes left or right. Delete is the operation worth actually watching step by step: removing a leaf or a node with one child is straightforward, but removing a node with two children involves finding its in-order successor (the smallest value in its right subtree) and promoting it, which this tool traces explicitly rather than skipping to the result.
Why left-to-right position always matches sorted order
Every node's horizontal position here comes from its rank in an in-order traversal — the same traversal that visits a BST's values in sorted order by definition. That's not a rendering coincidence: it's the direct, visual consequence of what a binary search tree actually guarantees — everything in a node's left subtree is smaller than it, everything in its right subtree is larger, all the way down.
The delete case worth watching closely
Deleting a node with two children can't just remove it — something has to take its place while keeping the BST property intact for every remaining node. The standard fix: find the in-order successor (walk into the right subtree, then keep going left as far as possible — the smallest value larger than the one being deleted), copy its value into the node being deleted, then remove the successor from its original position. The successor is guaranteed to have at most one child (a right child, possibly), so that second removal is always the easy leaf-or-one-child case — the hard case reduces itself to an easy one instead of needing separate handling.
What height has to do with performance
Search, insert, and delete are all O(height) — each comparison moves one level deeper, so the number of comparisons is bounded by how tall the tree is, not how many nodes it has. The "Height" and "Ideal height" stats make the gap between those two numbers concrete: a balanced tree keeps height close to log₂(n), but nothing about a plain BST enforces that. Clear the tree and insert 1 through 10 in order — every value becomes the right child of the last, producing a tree of height 9 for 10 nodes (instead of an ideal height of 3), which is exactly the O(n) worst case described in Time Complexity Interview Guide for an unbalanced tree, made directly visible instead of taken on faith.
FAQ
Why doesn't this tool rebalance the tree?
On purpose — self-balancing trees (AVL, red-black) are a real, important next step, but seeing a plain BST degrade under a bad insertion order is exactly what makes the case for why balancing matters in the first place.
What happens if I insert a value that's already there?
Nothing gets added — the walk finds the existing value and stops, reported explicitly as "already exists" rather than silently doing nothing.
How does this relate to the rest of the site?
See Hash Table Visualizer for a different approach to the same search problem — O(1) average instead of O(log n), at the cost of no ordering — and Time Complexity Interview Guide for the data structure operation cheat sheet this tool makes concrete.
Is anything I enter here sent anywhere?
No — every operation runs entirely in your browser. Nothing here is ever sent to a server.