Source Code

<div class="wrap">
  <div class="toolbar">
    <div class="mode-tabs" id="mode-tabs">
      <button class="mode-tab active" data-algo="bfs">BFS</button>
      <button class="mode-tab" data-algo="astar">A*</button>
    </div>
    <div class="controls-row">
      <button class="btn btn-primary" id="btn-run">Run</button>
      <button class="btn" id="btn-clear-walls">Clear Walls</button>
      <button class="btn" id="btn-reset">New Grid</button>
    </div>
  </div>
  <div class="legend">
    <span><i class="dot dot-start"></i>Start (drag)</span>
    <span><i class="dot dot-end"></i>End (drag)</span>
    <span><i class="dot dot-wall"></i>Wall (click/drag)</span>
  </div>
  <div class="grid" id="grid"></div>
  <div class="status-row" id="status-row">Click and drag to draw walls, then hit Run.</div>
</div>

Learn Coding Visually

Learn to code with interactive, live-preview playgrounds — HTML, CSS, JavaScript, React & more.

See all ->
HTML Playground42 lessons · Click-based · Live previewCSS PlaygroundLearn CSS with a live editorJavaScript Playground60 lessons · DOM · Async · CanvasReact PlaygroundLearn React with a live code editorGSAP PlaygroundLearn GSAP animation interactivelySVG Playground44 lessons · shapes · paths · animationSCSS Playground45 lessons · Sass modules · tokensTailwind PlaygroundLearn Tailwind CSS with a live editorBootstrap 5 Playground50 lessons · live preview

Pathfinding Grid Visualizer — Free HTML CSS JS Snippet

Pathfinding Grid Visualizer · Animations · Plain HTML, CSS & JS · Live preview

TagsCSS AnimationCSS Grid

What's included

Features

BFS implemented with a FIFO array queue — guarantees the first path found is shortest by unweighted edge count
A* implemented with an f = g + h priority list and an admissible Manhattan-distance heuristic
Search steps pre-computed into a flat array before animation, identical architecture to the sorting visualizer
Draggable start and end markers with collision protection against walls and each other
Click-and-drag wall drawing using a single mousedown/mouseover/mouseup handler trio, not per-cell listeners
Path reconstruction via a cameFrom map, the standard technique for backtracking a shortest route
Separate slower animation pass highlights the final shortest path in amber after the search completes
Clear Walls and New Grid controls reset different amounts of state for fast iteration

About this UI Snippet

Pathfinding Grid Visualizer — Animated BFS & A* Maze Search with Draggable Start/End and Wall Drawing in Vanilla JS

Screenshot of the Pathfinding Grid Visualizer snippet rendered live

Pathfinding visualizers are one of the clearest ways to make graph search algorithms tangible, because the "graph" is just a grid you can see and the "edges" are simply up/down/left/right neighbor cells. This snippet implements two classic algorithms — Breadth-First Search and A* with a Manhattan-distance heuristic — over a 24×14 grid where the user draws walls, drags the start and end markers, and watches the search expand cell by cell before the shortest path traces itself back.

Step pre-computation, same pattern as the sorting visualizer

Just like the sorting algorithm visualizer in this library, the search itself and its animation are fully decoupled. buildSearchSteps() runs BFS or A* to completion synchronously, producing a flat array of {type:'visit', r, c} and {type:'frontier', r, c} records plus the reconstructed shortest path array — none of that computation touches the DOM. Only afterward does run() walk the step array with a setTimeout loop, coloring one cell every 12 milliseconds. This means the search algorithm's correctness is never entangled with animation timing, and the exact same expansion order the algorithm computed is guaranteed to be what gets drawn, frame for frame.

BFS: queue mechanics and why cells "ripple" outward

BFS is implemented with a plain array used as a FIFO queue: queue.shift() removes the oldest-enqueued cell and queue.push() adds newly discovered neighbors to the back. Because cells are always processed in the order they were first discovered, and every step moves exactly one cell away from its parent, BFS explores the grid in concentric rings — first everything one step from the start, then everything two steps away, and so on. This is why the animation looks like a ripple expanding outward from the start marker: it's a direct visual consequence of FIFO ordering, not a special effect. Critically, the first time BFS reaches the end cell is guaranteed to be via a shortest path, because no cell farther away can ever be dequeued before all closer cells have already been processed.

A*: why the heuristic reshapes the search

A* replaces the plain queue with a priority list sorted by f = g + h, where g is the confirmed number of steps from the start and h is Math.abs(r - end.r) + Math.abs(c - end.c) — the Manhattan distance to the goal, chosen because it's an admissible heuristic on a 4-directional grid (it never overestimates the true remaining distance, which is what guarantees A* still finds the optimal path). Sorting the open list by f before popping each iteration (open.sort((a,b) => a.f - b.f)) means cells that are both close to the start and pointing toward the goal get explored first. Run BFS and A* on the identical maze back to back and the difference is visible immediately: BFS's ripple fills a full circle around the start regardless of where the end is, while A*'s frontier visibly stretches and leans toward the end marker, exploring far fewer irrelevant cells in open areas.

Grid state, wall drawing, and drag handling

The grid is backed by a plain 2D array of 0s and 1s (grid[r][c]), completely separate from the DOM cells array (cells[r][c]) that holds the actual div references — a deliberate split so pathing logic never has to read CSS classes or query the DOM to know if a cell is a wall. Wall drawing uses a single mousedown/mouseover/mouseup trio on the grid container rather than a listener per cell: mousedown starts a drag mode ('start', 'end', or 'wall'), mouseover events during the drag call setWall, and mouseup on the document (not just the grid) ends the drag reliably even if the cursor leaves the grid bounds mid-drag. Both start and end markers are just coordinates that get repainted, protected from ever landing on top of each other or on a wall.

Path reconstruction via a cameFrom map

Both algorithms populate a shared cameFrom object that maps each discovered cell's key to the coordinates of the cell that discovered it — the standard technique for reconstructing a path after any graph search without storing full paths at every node. Once the end cell is reached, animatePath() walks backward from end through cameFrom links until it reaches start, unshifting each cell onto a path array, then animates that path forward in amber with its own separate, slightly slower setTimeout loop so the final route is legible even after a fast search.

Build with AI

Build, Understand, Optimize, and Extend It With AI

Give this snippet's JavaScript to an AI assistant like Claude and ask it to explain exactly why the Manhattan-distance heuristic is admissible on a 4-directional grid, or to trace how cameFrom reconstructs the path after A* terminates. Good extensions to ask for: Dijkstra's algorithm as a third tab (A* without the heuristic term), a "diagonal movement" toggle with the heuristic swapped to Chebyshev distance, or a step counter comparing how many cells BFS versus A* visited on the same maze.

Prompt to recreate it

Copy this into your AI assistant of choice to build the effect from scratch, or as a jumping-off point for your own variant:

text
Build an interactive pathfinding grid visualizer in plain HTML, CSS, and JavaScript, no libraries or frameworks.

Requirements:
- Render a grid of div cells (roughly 24 columns by 14 rows) with a draggable green start marker and red end marker that the user can reposition by clicking and dragging.
- Let the user draw walls by clicking or click-dragging across empty cells, using a single mousedown/mouseover/mouseup listener trio on the grid container rather than one listener per cell.
- Implement Breadth-First Search using a plain array as a FIFO queue, exploring 4-directional neighbors and guaranteeing the first path found is shortest.
- Implement A* as a second selectable mode using a Manhattan-distance heuristic (h = |dr| + |dc|) combined with the confirmed path cost (g) to prioritize which cell to expand next, and explain in a comment why this heuristic is admissible.
- Pre-compute the entire search as a flat array of visit/frontier step objects before animating anything, then play back that array on a timer so the search algorithm and the animation speed are fully decoupled.
- Reconstruct the shortest path after the search completes using a cameFrom map recording which cell discovered each other cell, then animate that path separately in a distinct highlight color.
- Include Clear Walls and New Grid buttons, and a status line reporting whether a path was found and its length, or that no path exists.

Want to tighten it up first? Run this prompt through the AI Prompt Studio to score it across 8 quality dimensions, catch anti-patterns, and tune the wording for Claude, ChatGPT, or Gemini before you paste it in.

Step by step

How to Use

  1. 1
    Drag the green start marker or red end markerClick and hold on either marker, then drag across the grid to reposition it. The grid repaints instantly and blocks you from dropping one marker on top of the other.
  2. 2
    Click or drag across empty cells to draw wallsEach cell you click toggles into a dark wall cell; dragging with the mouse held down paints a continuous wall, letting you build a maze in seconds.
  3. 3
    Choose BFS or A* from the tabsBFS explores in expanding rings from the start. A* uses a Manhattan-distance heuristic to lean its search toward the end, usually visiting far fewer cells.
  4. 4
    Click Run and watch the search expandFrontier cells light up light indigo as they are discovered, then darken to a visited shade as they are processed — the expansion animates one cell at a time.
  5. 5
    Watch the shortest path trace in amberOnce the end cell is reached, the reconstructed shortest path animates backward-to-forward in amber, tracing the exact route from start to end through the maze.
  6. 6
    Use Clear Walls or New Grid to resetClear Walls empties the maze while keeping your start/end positions; New Grid resets markers to their default corners and clears everything for a fresh run.

Real-world uses

Common Use Cases

Teaching graph search and shortest-path algorithms
Run BFS and A* on the identical hand-drawn maze so students see the ripple-versus-directed-search difference directly, reinforcing why an admissible heuristic still guarantees optimality. Pair with the sorting algorithm visualizer for a complete algorithms-and-data-structures teaching module.
Interview preparation for graph traversal questions
BFS shortest-path and A* with heuristics are recurring technical interview topics. Building a maze and watching the queue-based ripple versus the heuristic-guided frontier live gives concrete intuition that static pseudocode does not.
Game development prototyping for grid-based enemy AI
Prototype tile-based enemy pathing or tower-defense pathfinding before wiring it into a game engine. The neighbors(), cameFrom, and step-array pattern port directly into a game loop once you swap the DOM cells for canvas or sprite rendering.
Interactive blog demo for a computer science article
Embed as a live, draggable demo inside an article explaining Dijkstra, BFS, or A*, letting readers build their own test maze rather than watching a fixed GIF. Works standalone in any UI snippets gallery with no build step.
Warehouse or robotics routing simulation mockups
Use the wall-drawing grid as a quick simulation mockup for robot or warehouse-picker routing problems, swapping the Manhattan heuristic for Euclidean distance if diagonal movement is later added.

Got questions?

Frequently Asked Questions

Yes. Move buildSearchSteps(), neighbors(), and the BFS/A* logic into a plain utils module — they take grid state as arguments and return data, so they need no framework changes. In React, run the animation loop inside a useEffect that stores its setTimeout id in a ref and clears it in the cleanup function when the component unmounts or Run is clicked again. In Vue, start the loop in a method and clear the pending timeout in onUnmounted or beforeUnmount. In Angular, manage the timer with a component field cleared in ngOnDestroy. The DOM/canvas cell painting is the only framework-specific part; the search algorithms stay pure functions.

BFS treats every direction as equally promising and expands in concentric rings regardless of where the end cell is. A* adds the Manhattan-distance heuristic to its priority score, so cells pointing toward the end are dequeued and explored before cells pointing away from it, even if both are the same number of steps from the start. In open mazes with few walls the difference is dramatic; in mazes with long forced corridors the two algorithms tend to converge because the heuristic offers less guidance when there is only one viable direction anyway.

No, not with this heuristic. Manhattan distance on a 4-directional grid where every move costs 1 is admissible — it never overestimates the true remaining distance to the goal — which mathematically guarantees A* still returns an optimal shortest path, it just typically explores fewer cells to get there. An inadmissible heuristic (one that can overestimate) could cause A* to return a suboptimal path, but that is not the case here.

Both algorithms exhaust their queue or open list without ever reaching the end cell, so cameFrom never gets an entry for the end coordinate. animatePath() detects the empty reconstructed path and shows "No path found" in the status line instead of attempting to animate a route, rather than throwing an error or looping indefinitely.

For diagonal movement, add the four diagonal offsets to neighbors() and switch the A* heuristic to Chebyshev or Euclidean distance, since Manhattan distance is not admissible once diagonal moves are allowed. For weighted terrain (e.g. slow "mud" cells), give each grid cell a cost value instead of just 0/1, and add that cost to g instead of always adding 1 when computing tentative — the rest of the priority-queue logic in the A* branch already supports variable edge weights without further changes.