Binary Search Tree Visualizer — Free HTML CSS JS Snippet

A binary search tree diagram in a textbook is always shown fully built, which hides the one insight that actually explains the structure: every node's position is the result of a chain of less-than/greater-than comparisons made one at a time, starting from the root. This snippet makes that chain visible — insert and search both animate a descent through the tree, pausing at each node to show the comparison being made, before finally landing on an empty slot or a matching node.

The tree is a real object graph, not an array

root is a plain JavaScript object with left/right pointers to child node objects, built with makeNode(value, x, y, depth, parentId). There is no array-based heap-style indexing here — the structure is exactly what a computer science textbook means by "binary search tree," a graph of nodes linked by real object references, the same representation used for the linked list visualizer elsewhere in this library. insertValue and searchValue both walk this graph with a plain while (true) loop, reading cur.left/cur.right and reassigning cur to descend, exactly like a real BST implementation would.

Why insertion never has to reposition existing nodes

Every node's horizontal position is computed once, at creation, from spreadForDepth(cur.depth) — a function that returns a smaller spread the deeper a node sits (Math.max(2.6, 26 - depth * 5.2)), so a new child's x-coordinate is simply its parent's x-coordinate shifted left or right by that shrinking amount. Because this value only depends on the parent's fixed depth and fixed x, not on how many other nodes exist elsewhere in the tree, inserting a new node never requires recalculating or animating the position of any existing node — this is the same "layout narrows per subtree by depth" arithmetic used in the recursion tree visualizer, adapted here to a binary (not fan-out) tree. The practical benefit: insert() can just append one new DOM element and one new SVG edge without ever touching the rest of the tree.

showCompare(): the mechanism that makes the algorithm legible

Both insertValue and searchValue call the same showCompare(node, value) helper at every step of the descent. It highlights the current node amber, attaches a small floating badge showing the literal comparison result — <, >, or = — computed with value === node.value ? '=' : (value < node.value ? '<' : '>'), waits long enough for a human to read it, then removes the badge and highlight. This single function is what turns "the algorithm compares and branches" from a claim into something you watch happen, one node at a time, in the exact order the real comparisons occur.

Search failure renders the counterfactual insertion point

When searchValue walks off the tree (next is null) without finding a match, it does not just report failure — it computes the exact x/y position a real insert of that value would use (via the identical spreadForDepth math insertValue uses) and renders a dashed, red, question-marked "ghost" node there with a brief shake animation before removing it. This answers the natural follow-up question a "not found" result raises — *where would it have gone?* — instead of leaving it abstract.

In-order traversal: why left, node, right always yields sorted order

inorderList(node, out) is the textbook three-line recursive definition: recurse left, push the current node, recurse right. Because every left subtree in a valid BST contains only smaller values and every right subtree contains only larger ones, visiting in that exact order necessarily visits every node from smallest to largest — this is not a coincidence of implementation, it is the defining property of the BST invariant itself. runInorder() computes the full traversal order first, then animates a small red marker dot flying (via a CSS transition on left/top) to each node's position in that order, briefly enlarging the node and appending its value to a running sequence readout — so the printed output is a live, checkable proof that the tree really is sorted.

Comparison badges and the ghost node share one visual vocabulary

Every transient piece of feedback in this snippet — the amber active highlight during a comparison, the green pulse on a search hit, the red shake on a duplicate insert or a failed search — uses the same small set of CSS classes toggled temporarily and removed after a fixed await wait(ms), mirroring the pacing pattern used throughout this library's other algorithm visualizers rather than relying on a general-purpose animation library.