Pathfinding Visualizer
Watch classic graph search algorithms find their way across a grid. Drag the start and target, paint walls and weighted cells, generate a maze, then animate A*, Dijkstra, greedy best-first, BFS or DFS and compare how many cells each one explores.
Last updated:
Comparison on this board
| Algorithm | Visited | Path length | Path cost | Shortest? |
|---|
How to use the Pathfinding Visualizer
- Pick an algorithm from the list. A short explanation of how it works appears under the grid.
- Edit the board: choose Wall, Weight or Erase and click or drag on the grid. Drag the green arrow (start) or the red target to move them.
- Generate a maze if you want a ready-made challenge: choose a maze type and press Generate maze.
- Press Start search to animate. Use the speed slider, Pause, or Step to go one cell at a time.
- Press Compare all algorithms to run every algorithm on the same board and see visited cells, path length, cost and whether each path is the shortest.
Pathfinding algorithms compared
| Algorithm | Data structure | Uses weights | Shortest path? | Time (grid with V cells) | Typical behavior |
|---|---|---|---|---|---|
| A* search | Priority queue on f = g + h | Yes | Yes, with an admissible heuristic | O(V log V) worst case | Narrow search aimed at the target |
| Dijkstra's algorithm | Priority queue on g | Yes | Yes (non-negative costs) | O(V log V) | Even ripples in all directions |
| Greedy best-first | Priority queue on h | No (ignores cost so far) | No | O(V log V) worst case | Very fast on open boards, fooled by walls |
| Breadth-first search | FIFO queue | No | Fewest moves only | O(V) | Layer by layer from the start |
| Depth-first search | LIFO stack | No | No | O(V) | Long single branches, lots of backtracking |
On a grid each cell has at most 4 neighbors (8 with diagonals), so the number of edges grows linearly with the number of cells and the binary-heap versions run in O(V log V).
Heuristics used for A* and greedy search
- Manhattan distance (four-direction moves): h = |Δrow| + |Δcol|. It is the exact cost on an empty grid with no weights, so it never overestimates.
- Octile distance (diagonal moves on): h = (|Δrow| + |Δcol|) + (√2 − 2) · min(|Δrow|, |Δcol|). It assumes you move diagonally as much as possible, each diagonal costing √2.
- Diagonal steps are only allowed when both neighboring straight cells are open, so a path never squeezes between two walls that touch at a corner.
- Ties in A* are broken in favor of the cell with the smaller h, which keeps the search focused when many cells share the same f value.
Experiments worth trying
- Weights versus BFS: paint a band of weights across the direct route. Dijkstra and A* walk around it; BFS walks straight through and reports a higher cost.
- Greedy trap: draw a U-shaped wall opening away from the target with the start inside. Greedy search fills the cup before escaping, while A* balances distance and cost.
- Perfect mazes: on a recursive backtracker maze every algorithm finds the same unique path; the difference is only how many cells each one explores first.
- Raise the weight cost to 20 and watch Dijkstra and A* take longer detours that still cost less.
Keyboard: focus the grid with Tab, move the highlighted cell with the arrow keys, press Space to draw with the selected tool, S to place the start and T to place the target.
Frequently asked questions
Which pathfinding algorithm is best?
For a single start and target on a grid, A* with an admissible heuristic is usually the best choice: it always finds the cheapest path, like Dijkstra, but explores fewer cells because the heuristic pulls the search toward the target. Dijkstra is better when you need distances to many destinations, and BFS is simplest when every move costs the same.
Does A* always find the shortest path?
A* is guaranteed to find a cheapest path when its heuristic never overestimates the true remaining cost (an admissible heuristic). This tool uses Manhattan distance for four-direction movement and octile distance for diagonal movement, both of which are admissible because every move costs at least 1 (or √2 diagonally).
Why does BFS find a longer or more expensive path when there are weights?
Breadth-first search counts moves, not costs. It finds the route with the fewest steps, so it will happily walk through weighted cells. Dijkstra and A* add up the cost of every cell they enter, so they detour around weights when that is cheaper. With diagonal moves turned on, BFS also treats a diagonal (cost √2) the same as a straight move.
Why is the DFS path so long and winding?
Depth-first search keeps going in the first available direction until it hits a dead end, then backtracks. It stops as soon as it reaches the target, so the path it reports is simply the branch it happened to be on, not an optimized route. DFS guarantees a path if one exists, but never that it is short.
What is the difference between Dijkstra and greedy best-first search?
Dijkstra orders cells by the cost already paid from the start (g), so it spreads out evenly. Greedy best-first orders cells only by the estimated distance to the target (h), so it rushes straight at the goal. Greedy is often much faster but can return a noticeably longer path, especially around walls and weights. A* combines both: f = g + h.
What do weights mean in this visualizer?
A weighted cell is passable but more expensive to enter, like mud or traffic. Entering it costs the weight cost you choose (5 by default) instead of 1. Walls cannot be entered at all. Path cost is the sum of the cost of every cell entered after the start.
How are the mazes generated?
The recursive backtracker carves passages with a randomized depth-first search, producing long corridors. Randomized Prim's algorithm grows the maze from a random frontier, giving many short dead ends. Recursive division starts with an open room and repeatedly splits it with walls that have one gap. All three produce perfect mazes with exactly one route between any two open cells.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.