Search the pages you already read

The idea

You read something three weeks ago with a number in it — a benchmark, a dosage, a pricing tier — and now you cannot find it. You remember the shape of the sentence, not the site. This is a browser extension that keeps its own full-text index of the pages you genuinely read, entirely on your machine, and gives you one search box over them. Not bookmarks, which you have to remember to create, and not history, which stores a URL and a title and throws the words away.

The distinction that makes it useful is "actually read". A day of browsing is four hundred URLs, and indexing all of them reproduces the noise you were trying to escape. The extension indexes a page when you scrolled it, stayed on it, and it had enough prose to be worth keeping.

Why build this

Search engines got worse at the long tail at the same time that the web got better at hiding old pages behind feeds. The pages you remember reading are frequently not findable again by search: they were a forum reply, a changelog entry, a personal blog, a doc page that has since been rewritten. Your own reading history is the one corpus guaranteed to contain what you are looking for, and it is the one corpus you cannot search.

The people who need this most read to work: developers, researchers, clinicians, anyone whose day involves reconstructing where a claim came from. The existing answers ask too much. Read-later apps require a decision at read time; note-taking tools require you to have already written something down; cloud archivers ask you to send your entire browsing stream to a server, which is a fair thing to refuse — this is your medical searches and your job hunt.

Now is a reasonable time because the whole thing finally fits in the browser. SQLite compiled to WASM with FTS5 gives you real ranked full-text search over tens of thousands of documents against origin-private storage, and a 90MB sentence-embedding model runs locally for the queries where keywords fail. Five years ago this design needed a server, and needing a server is what killed the privacy pitch.

Stack sketch

• Chrome/Firefox MV3 extension, TypeScript, Vite for the build.
• Capture: a content script that runs @mozilla/readability on the DOM at unload, gated by a read-detector — 20+ seconds of foreground time, meaningful scroll depth, and 200+ words of extracted text.
• Storage: wa-sqlite over OPFS, one database, an FTS5 table with the porter unicode61 tokenizer, and BM25 ranking. Store extracted text and a small excerpt, not raw HTML — the size difference is roughly 20x.
• Semantic fallback: transformers.js with all-MiniLM-L6-v2, embedding one vector per page in an idle-time queue, brute-force cosine over a Float32Array. At 50k pages that is 75MB and still runs in under 100ms.
• UI: the omnibox keyword for quick lookups, a full results page with date and domain filters, and an injected panel on Google and Kagi results showing "3 pages you've read".
• Sync, if any: end-to-end encrypted SQLite deltas to any S3-compatible bucket the user owns. Never a bucket you own.

Scope for v1

In: capture with the read-detector, FTS5 keyword search, the omnibox entry point, per-domain and per-date exclusion rules, a visible index size with a one-click purge, and Markdown export of everything.

Out: semantic search, sync across devices, mobile, PDFs, anything behind a login wall, and any form of summarization. Ship the index and the search box first — if keyword search over the right 5% of your browsing does not already feel useful, no amount of embedding fixes that.

Where it could go

The natural second act is answering questions instead of returning links. With a local index you can retrieve the five most relevant passages you have personally read and hand them to a model with citations back to the original pages, which is retrieval-augmented generation where the corpus is something you trust because you chose it. The privacy story stays intact if the retrieval is local and only the selected passages leave, and it stays fully intact if the model is local too.

Past that, the index is a useful primitive. Highlights and annotations get cheap once you have clean extracted text, a weekly digest of what you read grouped by topic is an interesting artifact on its own, and the same store supports a personal link-rot rescue: when a page 404s, you already have your own copy of it.

Watch out for

Capture is the part that will get you uninstalled. A content script that serializes the DOM on every page exit will be blamed for every slow tab whether or not it deserves it, so do extraction in an idle callback off the critical path and skip anything over a size ceiling. The other trap is capturing what the user never meant to keep — banking pages, health portals, private messages — so ship a sensible default denylist, respect incognito absolutely, and make "forget this page" reachable in one click from the results.