Full-Text Search vs. Title Search in Browser History

Full-Text Search vs. Title Search in Browser History

Browser history is good at proving that you visited a URL. It is much less helpful when you remember a sentence, code example, or idea from the page but not its title.

That gap comes from what each search method indexes. Title search works with a small metadata record: usually the page title and URL. Full-text search works with readable page text. Semantic search adds a representation of meaning, so related wording can match even when the query and source use different terms.

None of the three methods is universally best. A useful personal-history search tool combines them.

What title and URL search can recover

Title search is fast and predictable when the clue you remember appears in metadata. It works well for queries such as:

• a product or publication name;
• a distinctive documentation title;
• part of a hostname;
• an exact issue or repository name.

It fails when the title is generic. A page called “Getting Started,” “Dashboard,” or “Solved” may contain the exact answer you need without exposing any useful clue in its metadata. The same problem appears when a title changes after you visit or when the relevant detail sits several paragraphs into the page.

What full-text search adds

Full-text search indexes readable text captured from eligible pages. It can recover an exact error message, API name, quotation, or phrase even when that phrase never appeared in the title.

For example, imagine you remember reading “retry the request with exponential backoff” but not the article. A title-only search has nothing to match unless the author happened to use those words in the title. A full-text index can match the sentence itself.

Full-text search still depends on wording. If the page says “progressively increase the delay” and you search “exponential backoff,” a strict keyword engine may miss the conceptual match. That is where semantic search helps.

What semantic search adds

Semantic search converts captured text and the query into numeric embeddings. Nearby embeddings represent related meaning. A query such as “handling API limits without hammering the server” can therefore retrieve a page about exponential backoff even when the wording differs.

TraceMind generates embeddings on-device with a compact MiniLM model. Its local search combines semantic matches with exact full-text results, so a distinctive phrase is not discarded merely because a conceptually similar page also scores well.

This hybrid approach is useful because the two signals fail differently:

| Memory clue | Strongest first signal | |---|---| | Exact error, quote, or API name | Full text | | Topic or idea in different words | Semantic | | Site, product, or known title fragment | Title and URL | | Vague idea plus one exact detail | Hybrid |

What is actually captured

TraceMind captures readable text from eligible HTTP(S) pages as you browse. It does not promise to capture every page or every interface state. Browser-internal pages, restricted surfaces, authentication boundaries, and content that never loads can limit capture.

Core capture, indexing, search, screenshots, and analytics run locally in the browser. Optional Pro Chat is separate: when used, it sends the question and selected matching excerpts, titles, and URLs directly to the AI provider configured with the user's own key. TraceMind does not proxy or store those requests.

The Pro Offline Page Viewer can save sandboxed HTML reading copies. Those snapshots are useful when a source later changes or becomes unavailable, but they are not guaranteed complete archives; images and other resources depend on what was captured.

A practical search sequence

When a page is hard to recover, use the cheapest clue first and add context gradually:

1. Search the exact phrase or error you remember.
2. If that fails, describe the idea in natural language.
3. Add a domain or date filter if you remember where or when you read it.
4. Compare snippets and screenshot previews rather than relying only on titles.
5. Save or pin the result if it will remain important.

This sequence avoids a common mistake: rewriting the query again and again while keeping it trapped in title search.

The real distinction

Title search answers “which page name resembles these words?” Full-text search answers “which captured page contains these words?” Semantic search answers “which captured page discusses this idea?”

For personal browsing history, those are different retrieval jobs. Combining them is more reliable than treating one method as a replacement for all the others.

For the implementation trade-offs behind the local model and ranking pipeline, read Building Local-First AI: Technical Decisions. For hands-on retrieval tactics, see How to Find Pages You Visited Weeks Ago.