Sorting Algorithm Visualizer — Free HTML CSS JS Snippet

Most sorting visualizations you find online hardcode the animation directly into the sorting function — a setTimeout or await sleep() call sits right inside the comparison loop, which means the algorithm's actual logic and its on-screen playback speed are permanently welded together. This snippet takes a different, more reusable approach: every algorithm is compiled into a flat array of step objects before a single frame is drawn. Each step is a small descriptive record like {type:'compare', i, j}, {type:'swap', i, j}, or {type:'mark-sorted', i}. The sorting functions themselves — bubbleSteps, selectionSteps, insertionSteps, quickSteps, mergeSteps — run to completion synchronously against a plain copy of the array, pushing a step for every comparison and mutation, with zero knowledge of timing, DOM elements, or animation at all.

Why decoupling steps from playback matters

Once the full step list exists, a single tick() function walks it on a setTimeout loop, applying one step per call and scheduling the next with a delay computed from the speed slider (Math.max(4, 220 - speed * 2)). This separation is the single most important idea in the file, and it is the same pattern reused across the pathfinding grid visualizer (BFS/A* frontier expansion) and the recursion tree visualizer (call-stack push/pop events) in this library — any traversal or search algorithm can be pre-computed into steps, then replayed at any speed, paused, or even scrubbed backward, because the algorithm never has to be re-run to change the pacing. It also makes the counters trivially accurate: compares and swaps increment inside applyStep() exactly once per comparison or swap step, so the displayed numbers always match what's rendered, not an approximation.

How each algorithm is translated into steps

Bubble, selection, and insertion sort push one compare step per inner-loop comparison and one swap step whenever two elements exchange positions — the visual choreography follows directly from the textbook pseudocode, which is why bubble sort visibly "bubbles" the largest remaining value to the right on every outer pass. Quick sort adds a pivot step (colored violet) before partitioning around a[hi], using the Lomuto partition scheme, then recurses on the two sub-ranges exactly like the real algorithm — so the animation shows partitioning happening independently within shrinking sub-arrays, which is the detail that makes quicksort's average O(n log n) behavior visually distinct from bubble sort's O(n²) crawl. Merge sort is the odd one out: it doesn't swap in place, it overwrites. The mergeSteps function recursively splits the array, merges two sorted halves into temporary left/right slices, and pushes an overwrite step ({type:'overwrite', i, value}) for every value written back — so on screen you see bars snapping to new heights rather than trading places, which is an honest visual representation of merge sort actually needing auxiliary space.

Bar rendering and color-coded state

Each bar is a plain <div> with its height set as a CSS percentage and a transition: height 0.18s ease — so even though JavaScript sets the height instantly, the browser's compositor animates the visual change smoothly without any requestAnimationFrame bookkeeping. Four classes carry meaning: .compare (amber, applied to the two indices currently being examined), .swap (red, applied briefly to bars that just exchanged values), .pivot (violet, quicksort's anchor element), and .sorted (green, permanently applied once an index's final position is confirmed). clearHighlights() strips the transient amber/red classes before applying a new compare step so only the current comparison is ever highlighted, keeping the visualization readable even at high speed.

Speed slider and the setTimeout scheduling formula

The speed slider ranges from 1 to 100 and feeds directly into the delay formula 220 - speed * 2, clamped to a 4ms floor so that even at maximum speed there's still one animation frame's worth of breathing room and the browser doesn't lock up mid-sort on a 500-element style array. Because tick() re-reads the slider's value on every single scheduled call rather than caching it once, dragging the slider mid-sort changes the pace immediately — there's no need to restart the sort or rebuild the step list, since the steps and the timing are fully independent by design.

Why array snapshots avoid a subtle bug

Every *Steps function operates on arr.slice(), a shallow copy, rather than the live array variable. This avoids a bug that's easy to introduce: if the step-generation functions mutated the same array object that renderBars() reads from, the array would already be fully sorted before the first frame ever plays, because step generation runs synchronously and instantly, while playback is deliberately slow. Working on a copy guarantees the visualization always starts from the original shuffled state and only reaches the sorted state after all steps have actually played out on screen.