What you are looking at
The bars are an array. Their heights are the values. Everything else on the page describes what the algorithm is doing to that array at this exact moment: which two values it is comparing, which one it just moved, which positions it has finished with, and how much work it has done to get here.
The important thing is that nothing is animating at you. The algorithm has already run. What you are scrubbing through is a recording of every step it took, which is why you can go backwards.
Why stepping backwards matters
Most visualisers play an animation. That is fine for seeing the shape of a sort, and close to useless for the question a student actually has, which is usually some version of wait, why did it do that?
Answering that question means going back one step and looking again. So AlgoLab runs the algorithm to completion the moment you change the input, recording a full snapshot at every meaningful step. Playback is then just an index into that list. Stepping back and scrubbing to an arbitrary moment cost nothing, because nothing is being recomputed.
Reading the counters
The counters are the part most likely to change what you believe.
Comparisons and writes are counted separately, and shifts count as writes. That distinction is not pedantry. Insertion sort performs no swaps at all — it shifts elements along to open a gap — so a visualiser that counts only swaps will report zero writes for insertion sort and quietly teach you something false.
The complexity card puts the run’s actual comparison count next to the textbook bound evaluated at the current size. That pairing is the point. A bound tells you how the cost grows; the counter tells you what it cost this time. Seeing both at once is how n log n stops being a phrase and starts being a number you can predict.
Things worth trying
Run selection sort on sorted input. Then run it on reversed input. The comparison count does not move. Selection sort scans the whole remaining array to find the minimum regardless of what is in it, which is why it is the one common sort with no best case worth having.
Run insertion sort on nearly sorted input. Now the count collapses. Insertion sort is close to linear when the data is nearly in order, which is why it is used as the base case inside faster sorts and why O(n²) on its own is a misleading summary.
Set quicksort loose on few-unique input. Watch what the pivot does when most values are equal. This is the pivot starvation case, and it is the clearest argument for three-way partitioning.
Take binary search and give it a value that is not there. It still terminates in about log₂ n steps, and it ends on a frame that says so rather than stopping silently. Then try the same target with linear search and compare the step counts.
About the searches
Search algorithms need sorted data, so they run on a sorted copy of whatever array you give them, and the interface says so rather than sorting your input behind your back. Binary search halves the remaining range each step. Jump search steps forward in fixed blocks and then walks back through one, which lands between linear and binary in both cost and complexity.
Using your own data
The input box takes numbers separated by commas or spaces. If you are checking an answer from a problem set, paste the array from the question and scrub to the step the question asks about. That is the fastest way to find out whether you and the textbook disagree, and which of you is wrong.
Every link is shareable. The URL carries the algorithm, the input, the frame you are on and the speed, so sending someone a link sends them the exact moment you are looking at, not the tool with a fresh random array. Nothing you type is sent anywhere; the link is the only thing that travels, and it travels because you copied it.