Search Algorithm Visualizations
Search algorithm visualizations show the one thing prose struggles to convey: not just whether an algorithm finds the target, but the order in which it looks and what it gets to ignore. This collection animates the core search algorithms step by step, each synced to its real code, so you can watch a sorted array collapse by half, a graph fan out one ring at a time, or A* steer a frontier with a heuristic.
Every search is a bet about structure — except the first one. Linear search makes no bet at all: it reads every element in order until the target turns up, which is why it runs on any array and why, with nothing to exploit, it can do no better than O(n). Everything else here earns its speed by betting on structure. Binary search bets the data is sorted and wins big — one comparison throws away half the remaining elements. Two pointers makes the same sorted-data bet for a different question — which two elements pair up to hit a target — and collects it in a single linear sweep, dropping the end that provably cannot fit. Sliding window bets on different structure — that the answer is a contiguous run and the values never go negative — so one window that only ever grows its right edge and shrinks its left finds the best subarray in a single forward pass. Prefix sums bet that the array holds still: pay one pass up front for running totals, and every range sum afterwards is a single subtraction. Breadth-first and depth-first search make no such bet; they walk a graph node by node, and the only thing separating them is which node they agree to visit next. A* makes a riskier bet: a heuristic can point toward the goal without lying about the remaining cost. Learn to see those bets — halve the range, pick the next frontier node, trust a lower-bound hint — and you have the whole idea of searching.
How to Read a Search Algorithm
Open any visualization, press play, and watch four things:
- What does it rule out, and how fast? Binary search eliminates half the array on every probe — the discarded range fades out, and that fade is the O(log n). A graph search rules out nothing up front; it just marks nodes visited so it never processes one twice.
- What is the visit order? This is the entire difference between BFS and DFS. BFS uses a queue and visits the nearest unvisited node first, spreading outward in rings. DFS uses a stack (or recursion) and dives as deep as it can before backing up. Same graph, same O(V+E), completely different path.
- What does it require? Binary search demands sorted input — that requirement is the price of its speed. BFS and DFS work on any graph, but BFS alone finds the shortest path in an unweighted one, because "nearest first" and "fewest edges" are the same thing.
- When is the hint allowed to speak? A* adds a heuristic
hto the real costg. Ifhis consistent — 0 at the goal, and never falling by more than the cost of the step just taken — it focuses the search and keeps the shortest-path guarantee without reopening a closed node. Ifhlies high, the first goal it pops can be the wrong one.
Search Algorithm Comparison
| Algorithm | Searches | Time | Extra space | Needs | Visit order |
|---|---|---|---|---|---|
| Linear search | any array | O(n) | O(1) | nothing | front to back |
| Binary search | sorted array | O(log n) | O(1) | sorted data | halve the range |
| Two pointers | sorted array | O(n) | O(1) | sorted data | converge from both ends |
| Sliding window | contiguous subarray | O(n) | O(1) | non-negative values | grow right, shrink left |
| Prefix sums | range sums | O(n) build, O(1) per query | O(n) | an array that rarely changes | two fences, one subtraction |
| Breadth-first search | graph / tree | O(V + E) | O(V) | a queue | nearest first |
| Depth-first search | graph / tree | O(V + E) | O(V) | a stack | deepest first |
| Tree traversal | binary tree | O(n) | O(h) | recursion / a stack | pre / in / post |
| Connected components | undirected graph | O(V + E) | O(V) | a visited set | sweep, fill each island |
| A* pathfinding | weighted grid / graph | O((V + E) log V) | O(V + E) | consistent heuristic | smallest g + h first |
The honest comparison is that these barely compete. Binary search and graph search answer different questions — "is this value in this sorted list" versus "how is this node connected to that one." BFS and DFS are the real pair: identical cost, opposite temperament. A* is the shortest-path specialist: it borrows Dijkstra's priority queue and adds a heuristic to avoid searching the whole neighborhood when the goal has a direction.
A Recommended Learning Order
Start with linear search, the O(n) floor every other search is measured against. It checks elements one at a time and stops the instant it matches, and it asks nothing of the input — no sorting, no structure — which is exactly why it can do no better than reading the whole array. It frames the question the rest of the collection answers: given more structure, how much work can you skip? Binary search gives the sharpest answer. It is the cleanest demonstration of the most valuable idea in searching — that ruling things out is as good as finding them — and the math is unforgiving and beautiful: a million sorted elements cost at most twenty probes, against linear search's million. Follow it with two pointers, binary search's linear cousin on sorted data: instead of halving a range it walks one index in from each end, and the same ordering that powers binary search is what makes each move safe — the breaking case, an unsorted array that silently skips a real pair, is where the lesson earns its keep. Next, sliding window, two pointers' same-direction counterpart: instead of converging from the ends, both indices march forward — the right edge grows the window, the left edge shrinks it — so each element is added once and removed once for an O(n) sweep over contiguous subarrays, and its breaking case is a negative value that lets the greedy shrink walk past a shorter valid window. Close the array set with prefix sums, which stops searching for a window and precomputes every answer instead: one O(n) pass writes running totals, and each range sum becomes prefix[r + 1] − prefix[l], two reads whatever the length. Its breaking case is a point update, which makes every later total stale. Then breadth-first search, which generalizes "search" from a line to a graph and earns its keep by finding the shortest unweighted path as a side effect of visiting nearest-first. Pair it with depth-first search, BFS's mirror image: swap the queue for a stack and the algorithm stops spreading and starts plunging. Specialize that plunge to a binary tree and you get tree traversal: the same depth-first walk, where the only remaining choice is when each node is recorded relative to its two children's recursive calls — the one moved line that names preorder, inorder, and postorder. Then step up from walking one component to cataloguing them all with connected components: an outer loop restarts a flood-fill at every still-uncolored vertex, and the number of restarts is the number of islands — its breaking case, an isolated vertex that is a component all by itself, is the one people forget to count. Finish this set with A pathfinding*, where the frontier is no longer FIFO or LIFO but sorted by g + h; the overestimating-heuristic failure case is where the lesson earns its keep.
All Search Visualizations
Pick any search below to open its interactive player — change the input or the graph, step through it, and watch the code highlight move in lockstep with the animation.