JavaScript Live Search Filter: 7 Steps to Build One From Scratch

Ever typed into a search box and watched a long list shrink instantly, no page reload, no spinner, just the exact rows you wanted? That is a javascript live search filter doing its job, and below is real working code proving it, keystroke by keystroke.

A javascript live search filter listens to an input field, compares whatever the visitor typed against a list of items, and renders only the ones that match back onto the page. No framework is required for this, plain JavaScript handles the whole thing in well under a hundred lines.

The pattern shows up constantly once you start looking for it: a product catalog narrowing as a shopper types a model number, a documentation site jumping straight to the matching page title, a settings screen with dozens of options collapsing down to the two that matter. The mechanics behind all three are identical to what gets built below.

Nielsen Norman Group's research on search usability makes a simple point worth keeping in mind here: visitors expect results to update as they type, not after a separate button click, which is exactly the behavior this pattern delivers.

A javascript live search filter also has a real cost advantage over a server backed search. Every keystroke that stays entirely inside the browser is one less request hitting a backend, one less database query, and one less round trip a slow connection has to wait through, which matters most for a list that already lives on the page as plain data.

The matching logic itself is nothing more than a case insensitive substring check, run once per item in the list using the built in Array.prototype.filter.

function normalize(str) {
  return str.trim().toLowerCase();
}

function filterItems(items, query) {
  const q = normalize(query);
  if (!q) return items;
  return items.filter((item) => normalize(item).includes(q));
}

Trimming and lowercasing both sides before comparing matters more than it looks. Without it, a visitor typing "bluetooth" would miss "Bluetooth Speaker" entirely just because of capitalization, which is a frustrating and completely avoidable bug in a javascript live search filter.

Run against a real list of 15 product names and five different real queries, mixed case, extra whitespace, and a query with zero matches, the function behaves exactly as expected in every case.

Actual output from filter.js, run against 15 real product names and 5 real queries.

Wiring the filter straight to every keystroke works, but it means filtering and rendering the entire list all over again on every single character typed, wasted work on a long list or a slow device. The fix is the same debounce pattern covered in an earlier guide.

function debounce(fn, delay) {
  let timer = null;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

const debouncedFilter = debounce(runFilter, 200);
searchInput.addEventListener('input', (e) => debouncedFilter(e.target.value));

A real browser test proves the point better than a description of it. Ten actual keystrokes typed into a real input field, 60 milliseconds apart, all landing well inside a 200 millisecond debounce window.

Ten real keystrokes, one real filter run. Real Chromium via Playwright, not a simulated timeline.

web.dev's guidance on input handlers covers the same trade off from a page performance angle: an undebounced handler on a large list is a common, avoidable cause of a sluggish feeling interface.

Showing which part of each result actually matched makes a javascript live search filter feel noticeably more polished, and it takes only a small amount of extra string handling.

function highlightMatch(item, query) {
  const idx = normalize(item).indexOf(normalize(query));
  if (idx === -1) return item;
  return item.slice(0, idx)
    + '<mark>' + item.slice(idx, idx + query.length) + '</mark>'
    + item.slice(idx + query.length);
}

The <mark> tag used above is not an arbitrary styling choice. The HTML Living Standard defines it specifically for marking a run of text relevant to the current context, which is precisely what a search match is, and it gets sensible default styling in every browser without any CSS required.

The version above only wraps the first occurrence of the query in a given string, which is fine for most product names and titles but worth knowing as a real limitation. Highlighting every occurrence needs a small loop over each match position instead of a single indexOf call, useful when the searchable text is a longer paragraph rather than a short title.

A query that matches nothing is not an error condition, it needs its own clear state in the rendered list rather than silently showing an empty container.

function renderResults(matches, query) {
  if (matches.length === 0) {
    resultsEl.innerHTML = `<li class="empty">No results for "${query}"</li>`;
    return;
  }
  resultsEl.innerHTML = matches.map((m) => `<li>${highlightMatch(m, query)}</li>`).join('');
}

An empty result also needs to be announced to a screen reader, not just visible on screen. Wrapping the results container in an ARIA live region, checkable directly in Chrome DevTools' Accessibility panel, means a visitor using a screen reader hears "no results" the moment it happens instead of silence.

A query that matches everything deserves the same attention as one that matches nothing. Clearing the input field entirely should restore the full original list immediately, not leave the last search's results stuck on screen, and the empty string check already built into filterItems from section two handles that case correctly without any extra code.

A plain Array.prototype.filter scan through the whole list on every run is fine for hundreds of items. Past a certain point, list size, match complexity, or the need for fuzzy matching starts to matter more.

For genuinely large datasets or typo tolerant matching, a small dedicated library like Fuse.js handles fuzzy scoring that a hand rolled substring check was never designed to do, at the cost of one extra dependency.

Memory is rarely the bottleneck for a javascript live search filter running entirely client side, even a list of several thousand short strings is a trivial amount of data for a browser to hold. The real cost, filtering and rendering time, scales with how often the function runs and how much DOM work each run triggers, which is exactly what the debounce pattern from earlier keeps in check.

Whichever approach gets used, keep an eye on Interaction to Next Paint. A javascript live search filter that takes noticeably long to render the list again on every keystroke is exactly the kind of interaction that metric is designed to catch, and the same debounce pattern from earlier is often the simplest fix for it.

Measuring that render time is worth doing before assuming a fuzzy search library is needed at all. Chrome DevTools' Performance panel timestamps exactly how long each filter and render cycle actually takes on the list in question, and on most real product catalogs and documentation sites the plain substring approach above finishes in well under a millisecond, far below anything a visitor could perceive.

Most bugs in a homemade search filter trace back to one of these five habits. None of them are exotic, and every single one is easy to catch with a quick manual test against a handful of real queries before shipping.

Testing with a genuinely empty list is worth doing too, not just a list that temporarily has zero matches. A search box rendered before its underlying data has finished loading should show a clear loading state rather than an empty state that looks identical to "nothing matched," since the two situations mean completely different things to a visitor.

• Comparing without normalizing case: a query typed in the wrong case silently misses results that should have matched.
• Skipping the debounce entirely: filters and renders the full list all over again on every keystroke, wasting work proven avoidable above.
• Rebuilding the entire DOM instead of just the list: rendering more than the results container causes unnecessary layout work and can even reset focus on the input field itself.
• No empty state: a visitor who searches for something with zero matches sees a blank area and has no idea whether the filter is broken or genuinely found nothing.
• Ignoring screen reader users: a purely visual result count update, with no ARIA live region, according to CSS-Tricks' guide to live regions, leaves a whole category of visitors with no indication results changed at all.