Linear Search Visualization — Step by Step

One pass, left to right

Linear Search is the algorithm you would invent yourself: start at index 0 and check every element in turn until you find the target or run out of array. There is no preprocessing, no assumptions about order, and no extra memory — just a single loop and one comparison per element. That simplicity is the point. Every other search technique, from binary search to hash tables, is an answer to the question "how do we avoid looking at everything?" — and linear search is the baseline they are all measured against.

A concrete trace

Search [12, 5, 8, 21, 8] for the target 8. Index 0: compare 12 with 8 — no match, move on. Index 1: compare 5 with 8 — no match. Index 2: compare 8 with 8 — match, return index 2 after three comparisons. The search stops at the *first* occurrence: the second 8 at index 4 is never examined. In the visualizer you can watch exactly this — each cell lights up as it is visited, gets compared against the target, and the search halts the moment the match event fires.

Best, worst, and average cases

Where the target sits determines the cost. If it is at index 0, one comparison suffices — the O(1) best case. If it is the last element, or absent entirely, all n elements get checked — the O(n) worst case. For a target in a random position, you examine about n/2 elements on average, which is still O(n): constants are dropped in Big-O. The early exit matters in practice though — searches that usually hit near the front of the array behave far better than the worst case suggests.

Why it works on anything

Linear search demands almost nothing from its data. The array can be unsorted, contain duplicates, or hold objects with no natural ordering — you only need an equality check, and the check can be any condition at all ("first user whose age exceeds 30"), not just equality. It also works on structures without random access: scanning a linked list node by node *is* a linear search. This universality is why language built-ins like JavaScript's indexOf and find, or Python's in operator on lists, are linear searches under the hood.

The cost of no preparation

Compare the running totals against binary search on sorted data: at 1,000 elements, linear search averages around 500 comparisons while binary search needs about 10. At a million, it is roughly 500,000 versus 20. The lesson is not that linear search is bad — it is that preprocessing buys speed. Sorting enables binary search; hashing enables O(1) average lookups. When you search once, preparation costs more than it saves. When you search constantly, linear search is the wrong tool.

JavaScript

function linearSearch(arr, target) {
  for (let i = 0; i < arr.length; i++) {
    if (arr[i] === target) {
      return i; // first matching index
    }
  }
  return -1; // reached the end without a match
}

// The same idea works for any condition, not just equality:
function findIndexBy(arr, predicate) {
  for (let i = 0; i < arr.length; i++) {
    if (predicate(arr[i])) {
      return i;
    }
  }
  return -1;
}

Python

def linear_search(arr, target):
    """Return the index of the first occurrence of target, or -1."""
    for i, value in enumerate(arr):
        if value == target:
            return i
    return -1


def linear_search_all(arr, target):
    """Return the indices of every occurrence of target."""
    return [i for i, value in enumerate(arr) if value == target]

Java

public class LinearSearch {
    public static int linearSearch(int[] arr, int target) {
        for (int i = 0; i < arr.length; i++) {
            if (arr[i] == target) {
                return i; // first matching index
            }
        }
        return -1; // not found
    }

    public static void main(String[] args) {
        int[] data = {12, 5, 8, 21, 8};
        System.out.println(linearSearch(data, 8)); // prints 2
    }
}