b2KIT

Pathfinding Algorithm Visualizer

Watch A*, Dijkstra, and BFS find shortest paths on grids. Draw walls, add weights, and compare algorithm exploration patterns.

Tested tool guide Tested browser tools Checked August 16, 2026

What Pathfinding Algorithm Visualizer does and how it behaves

This tool runs three search algorithms (breadth-first search, Dijkstra, and A*) on a grid you configure by dragging a start cell, an end cell, walls, and optionally weighted cells, then animates each one cell by cell so you can see the order nodes are visited before the final path is drawn. The part people misread is the word 'shortest': BFS counts steps only, so on a weighted grid it can highlight a path that is short in cell count but not the cheapest one, while Dijkstra and A* optimize total cost and can legitimately draw a longer-looking route.

How the result is produced

1

Grid, walls, and weights

You place a single start and end cell on a rectangular grid, then click or drag to toggle cells into walls (impassable) or weighted cells (passable but costlier to enter). Each algorithm run treats walls as removed nodes and weights as added traversal cost, then steps through the search so you can watch the visited set and frontier grow before the final path is traced back from the end cell.

2

Why the three algorithms diverge

BFS expands nodes in ring order by number of steps and has no concept of cell cost, so it ignores weights when choosing a path. Dijkstra expands by lowest cumulative cost using a priority queue, correctly respecting weights. A* does the same but adds a distance-to-goal heuristic that biases expansion toward the end cell, typically visiting fewer cells than Dijkstra while still returning an optimal-cost path.

Good uses

  • Building intuition for a data structures or algorithms course by watching BFS, Dijkstra, and A* explore the same maze side by side
  • Sanity-checking, before implementing pathfinding in a game or robotics prototype, how much a heuristic actually cuts down explored nodes versus Dijkstra
  • Preparing for a technical interview question on graph search by seeing concretely how weighted edges change which algorithm's answer is 'correct'

Limits and checks

  • BFS on a grid with weighted cells will still show a completed path, but that path minimizes step count, not total weight, so it can disagree with Dijkstra and A* by design, not by bug
  • Whether the grid allows diagonal movement, and how ties between equal-cost cells are broken during expansion, changes both the drawn path and the visited-cell count; treat those specifics as configuration to check in the tool itself rather than something this profile can assume
  • A blocked-off start or end simply yields no path; that is the correct result for all three algorithms, not a sign the visualizer is broken

Common questions

Will A*, Dijkstra, and BFS always draw the same path?

Only when every passable cell costs the same to enter and there is a single unique shortest route. As soon as you add weighted cells, BFS's fewest-cells path can differ from the lowest-cost path that Dijkstra and A* return, and with multiple equal-cost routes the algorithms can pick different ones depending on tie-breaking.

Does A* explore fewer cells because it's a 'better' algorithm?

It explores fewer cells because its heuristic estimates distance to the goal and prioritizes promising directions, whereas Dijkstra expands uniformly outward by cost with no sense of where the goal is. A* still needs an admissible heuristic to guarantee an optimal path; it's a smarter search, not a fundamentally different guarantee.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools