SHSelfHostIndex
PA

Pagefind

Static-site search that runs fully in the browser

Search Engines ★ 5.5k stars Easy setup MIT

Pagefind is a fully static search library that indexes a built website and serves search entirely from the browser without a backend. It is designed to be low-bandwidth and easy to add to any static site.

Official siteSource code

Key features

  • Browser-side search index
  • No backend required
  • Low bandwidth
  • Multilingual support

Pros & cons

Strengths

  • Zero server cost
  • Trivial to deploy

Trade-offs

  • Static content only
  • Index rebuild on changes

Pagefind replaces

Self-hosted Algolia alternativesSelf-hosted Elasticsearch alternatives

Last reviewed Sep 13, 2026 · 849 words

There is nothing to host. Pagefind runs once, after your static site generator finishes, and writes a search index into the output folder as a set of small chunks; the browser fetches only the chunks a query needs. A 10,000-page site searches from the visitor's machine with a few hundred kilobytes of transfer and zero server-side code, which is why the "self-hosted search" question for a static site is usually answered with Pagefind (5,400 stars, MIT, Rust, first released 2022) rather than with a search server at all.

How a static-site owner actually uses it

Pagefind is a build tool plus a JavaScript UI, not a service. The whole integration is one command after the site builds:

hugo && npx pagefind --site public

That scans every HTML file under public/, extracts the text, and writes a public/pagefind/ directory containing the index chunks, a WebAssembly search engine, and a default UI script. Deploy public/ as usual. The CLI is a single Rust binary, so npx is a convenience; you can download the release binary and call it from any CI step. It works with Hugo, Astro, Eleventy, Jekyll, or a folder of hand-written HTML, because it only ever looks at the output.

Then, on the page where you want a search box:

<link href="/pagefind/pagefind-ui.css" rel="stylesheet">
<script src="/pagefind/pagefind-ui.js"></script>
<div id="search"></div>
<script>
  window.addEventListener('DOMContentLoaded', () => {
    new PagefindUI({ element: "#search", showSubResults: true });
  });
</script>

That is the entire deployment. Results appear as the visitor types, with excerpts and highlighting, and the page never contacts a backend.

Data attributes decide result quality

Out of the box Pagefind indexes the <body>, which means your navigation, footer, and cookie banner are in every result. Four attributes fix that and are worth 20 minutes in your templates. data-pagefind-body on the article container restricts indexing to that element for every page that has one, and pages without it are dropped entirely, which is usually what you want for tag listings and pagination. data-pagefind-ignore on an element inside the body excludes it, for sidebars and share buttons. data-pagefind-meta="title" or "image" populates the result card; the title is picked up from <h1> automatically, the image is not. data-pagefind-filter="category" on an element turns its text into a facet the UI can filter by, which is how a docs site gets a "section" dropdown without writing any code.

Weighting is possible with data-pagefind-weight, and headings already count more than body text. Multilingual sites get separate indexes per lang attribute automatically, with stemming for the languages Pagefind supports.

The bandwidth trick is the reason it scales

A traditional client-side index (Lunr, Fuse) ships the whole index to every visitor, so it stops being viable at a few hundred pages. Pagefind splits the index by word fragment and loads chunks on demand, and the chunks are content-addressed so they cache forever. The project's own numbers put a 10,000-page site at roughly 300 KB of transfer for a typical search. The index directory on disk will be larger than that, often tens of megabytes for a big site, but visitors never download it whole. This matters for Core Web Vitals on static sites because the search UI loads nothing until someone types.

Where you outgrow it

Pagefind indexes what exists at build time. Content that changes between builds (comments, user-generated pages, anything behind a login) is invisible until the next deploy, and there is no API to add a document at runtime. Ranking is good but not tunable the way a server-side engine's is: no synonyms, no typo tolerance beyond the stemmer, no learned relevance. When you need instant search over a database, or search across content the site does not render, Meilisearch is the self-hosted engine to reach for and the bigger project in the search category. Pagefind is not competing with it; it removes the need for it on the sites where all the content is already HTML.

Cost and privacy compared with the hosted option

The hosted alternative for static sites has for years been Algolia, which is excellent and sends every keystroke of every visitor to a third party, on a plan whose free tier is fine until the day it is not. Pagefind costs nothing per query, leaks nothing, and needs no API key in your client bundle. For a blog, a docs site, or a directory like this one, that trade is not close.

What I'd do

Add npx pagefind --site public as the last line of the build, put data-pagefind-body on the article template and data-pagefind-ignore on the sidebar, drop the default UI into the header, and ship it. Revisit the decision only when the site has content that is not static HTML, at which point Meilisearch is the upgrade path. For most static sites, that day never comes.

Compare Pagefind

28 head-to-head comparisons.

Similar search engines apps