Binary Search Visualizer — Free HTML CSS JS Snippet

Binary search is usually taught with a paragraph of pseudocode and a static diagram, which hides the thing that actually makes it fast: every single comparison throws away half of what's left. This snippet makes that visible by animating the low, mid, and high pointers as they crawl across a row of sorted number boxes, dimming the eliminated half after every comparison and printing a plain-English log line for each step.

Why the array must be sorted

Binary search's entire correctness argument depends on one guarantee: if array[mid] is less than the target, every value to the left of mid is also less than the target, so the whole left half can be discarded without checking it individually. That guarantee only holds because the array is sorted ascending. This snippet enforces it structurally — randomArray() builds a Set of 16 unique random integers and immediately calls .sort((a,b) => a - b) before the array is ever rendered, so there is no code path that produces an unsorted state. If you swap in your own data, sorting it first isn't optional decoration, it's the precondition the entire algorithm depends on; run this same logic on unsorted data and the left/right elimination becomes wrong on the very first step.

Step pre-computation, same architecture as the sorting visualizer

buildSteps(target) runs the full binary search synchronously before any animation happens, pushing one record per comparison: {lo, hi, mid, value, target}, followed by either a {found: true, mid} or {notFound: true} terminal step. This mirrors the step-array architecture used across this library's other algorithm visualizers — the search logic and the on-screen playback are entirely separate concerns. The advantage here specifically is that the log panel and the box highlighting are guaranteed to describe exactly the same sequence of comparisons, since both are driven off the identical pre-computed step list rather than being narrated separately.

The O(log n) intuition made concrete

Each step computes mid = Math.floor((lo + hi) / 2) and then narrows either lo to mid + 1 or hi to mid - 1 — never both, and never a small adjustment, always cutting the live range [lo, hi] exactly in half. With 16 elements, that means the range shrinks 16 → 8 → 4 → 2 → 1, so the search is guaranteed to finish in at most 4 comparisons regardless of where the target sits or whether it's present at all. That is the entire content of "O(log n)": every step does a constant amount of work but eliminates a *proportion* of what's left rather than a fixed count, so the number of steps needed grows logarithmically, not linearly, as the array grows. Doubling the array to 32 elements adds only one more possible step, not sixteen — a fact that becomes visually obvious once you've watched the elimination happen a few times.

Rendering the elimination and pointer animation

Every comparison step repaints all boxes: indices outside the current [lo, hi] window get the .eliminated class (22% opacity, slightly scaled down via a CSS transition), indices still in play get a light indigo .range background, and the mid box itself gets a distinct violet .mid style with a scale-up and shadow so it's unmistakable which element is being compared right now. A separate row of pointer labels above the boxes — L, M, H in cyan, violet, and red respectively — is cleared and repositioned above the correct box index on every step using querySelectorAll('.ptr')[index], giving a textbook-style visual of the three pointers converging without needing any SVG or canvas.

The comparison log as a plain-English trace

Every step also appends a line to the log panel in the exact format lo=3 hi=10 mid=6, arr[6]=42 > 30, search left half — deliberately readable without any algorithm background, generated by a simple three-way branch comparing value to target. This log is what turns an abstract animation into something closer to a textbook walkthrough: a learner can pause at any point, read the last log line, and understand exactly why the algorithm chose to look left or right next, reinforcing the pointer movement they're watching simultaneously above.

Async/await pacing instead of a manual timer loop

Unlike the sorting and pathfinding visualizers in this library, which use a setTimeout-driven tick() function, this one uses a single async function runSearch() with a wait(ms) helper that wraps setTimeout in a Promise. Because binary search never has more than a handful of steps (at most log2(n)), a simple for...of loop with await wait(650) between iterations is simpler to read and reason about than a recursive scheduler, while still keeping the algorithm (buildSteps) and the animation (runSearch) in clearly separate functions.