Explainers · measured July 2026 · 8 min read
What is full-text search? The trick that finds any word without opening a file.
The short version: full-text search reads every document once and builds a map from words to the files that contain them, so every search after that is a single lookup, not a fresh read of the disk. It is why a search box can answer in the time it takes to blink, and why the one on your own machine, when it does this badly, makes you wait.
You already know both sides of it. Type into Google and ten billion pages resolve to ten results before you lift your finger. That is an index. Run grep on a folder, or ask Windows Search for a word buried inside your files, and something reads through everything, one file at a time. That is a scan. One looks up. One reads. On a real machine, that gap is the difference between 16 milliseconds and a minute and a half.
The definition
It is a lookup, not a read.
Full-text search is a technique that indexes every word in every document ahead of time, so any word or phrase can be found instantly by consulting that index, instead of opening and reading each file's contents from top to bottom on every query. The name is literal: it searches the full text of your files, not just their titles. The classic way to build the map is an inverted index: a list that, for each word, already holds the files that contain it.
The idea. Full-text search indexes every word in every file ahead of time, so any phrase is found by a lookup instead of a scan.
Scan vs index. Scanning (grep, Ctrl+F, Windows Search over contents) reads every file on every query, so its cost grows with your disk. An index reads everything once, then jumps straight to the answer.
The payoff, measured. On a 4.47-million-file machine, a content-word lookup returns in 16 ms where grep scans for 93.8 s: the same query, about 5,900× faster.
The hard part. Building the index is easy. Keeping it true as files change is the real work: a stale index answers confidently and wrong.
Where you meet it. Every fast search box you love runs on one; every slow one is scanning. Interlinked puts a live one over your whole machine.
The trade is simple. You pay once (a single full read of everything, done in the background when nobody is waiting) and in exchange every query afterward is a jump to a row that is already assembled. Scanning pays nothing up front and then pays on every single search, forever.
The two strategies, drawn
One reads every file. One reads a map.
Ask both approaches for the word coffee. A scan has no map, so it does the only thing it can: open the first file, read it, open the next, read it, all the way down. A full-text index skips straight to the row for coffee, which already lists the two files that hold it, and it opens nothing else. Same question, same disk, two completely different amounts of work.
Top: a scan opens and reads all eight files (the eight stand in for every file on the machine) and finishes in 93.8 s. Bottom: the index looks up the word, follows it to just the two matching files, and finishes in 16 ms. The cost of a scan is set by the size of the disk; the cost of a lookup is set by the number of matches. That is the whole difference.
Same machine · same drive · same words
Seconds when you scan. Microseconds when you look up.
The tools people already use split cleanly into the two strategies. grep and ripgrep scan; VS Code's find-in-files and Windows Search walk the tree the same way. Point any of them at a whole machine and the reading is the cost. A prebuilt full-text index turns each of those into a lookup. Measured on one real machine:
| The tool | How it works | Time | vs the index |
|---|---|---|---|
| Find a word inside your files: full-text content search | |||
| Interlinked | reads the index | 16 ms | look-up |
| grep / ripgrep | scans every file | 93.8 s | 5,863× slower |
| Find a file by its name | |||
| Interlinked | reads the index | 85 µs | look-up |
| Windows Search | scans, then waits | 67 s | ~480,000× slower |
| VS Code Ctrl+P | walks the tree | 35 s | 412,000× slower |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename look-ups are an 85 µs single-file result and a 139 µs median across 20 queries (2 µs best case). The content row is one query: grep read for 93.8 s where the index answered in 16 ms; across the five-query content set the look-up averaged 7 to 9 ms, 58,625× faster. Full per-tool method in the ripgrep comparison, the VS Code write-up, and the Windows Search breakdown.
The part that is actually hard
Building the index is easy. Keeping it live is the job.
A full-text index is only worth anything if it matches reality. The moment you edit a file, the old map is wrong: it points at words that moved and misses words you just wrote. And a stale index is worse than no index, because it answers confidently and answers wrong. This is where most attempts quietly fall over: they build a beautiful map on Monday and let it rot by Friday, or they rebuild from scratch so often that they are half-scanning anyway.
The real engineering is not the map: it is a live map, one that updates the instant a file changes so it stays both fast and correct without ever being rebuilt. Get that right and every query is a lookup, forever, over a picture of the disk that is never more than a moment old.
Full-text search for the whole machine
A search box over everything you own. Look up, never scan.
This is the whole idea behind Interlinked. The move a web search engine makes across billions of pages (and that code-search tools like Sourcegraph and Glean make across a company) Interlinked makes across the disk in front of you: read everything once, keep a live full-text index from words and names to the files that hold them, and answer every query as a lookup. Every repo, plus the ninety percent of the drive that was never in a repo: configs, documents, downloads, the PDF with the answer.
And there is no model in the loop: no embeddings, no guessing, no cloud round-trip. A lookup is a lookup: a word, a row, a list of files. The whole engine sits around 44 MB at rest (less than one browser tab) and the index takes under 1% of the drive. Everything stays on the machine; nothing leaves. It is the same fast floor every AI agent stands on, which is the larger story in the backbone of the LLM economy.
Questions people ask
Full-text search, answered.
Is full-text search the same as grep?
No. grep scans: it opens and reads files on every query, which is exactly right for a single file or a live pipe. Full-text search reads everything once, then answers from a prebuilt index. The moment you search a whole machine repeatedly, the index wins: 16 ms against grep's 93.8 s on the same query.
What is the difference between full-text search and semantic search?
Full-text search matches the actual words you typed and simple variants of them. Semantic search matches meaning, using embeddings and a model, so it can surface concepts you never named. Full-text is exact, instant, and needs no model; semantic is fuzzier and heavier. They answer different questions.
Does Windows Search use full-text search?
In part (it does index some file contents) but on a real 4.47-million-file drive it still returned a median query in 67 seconds in our test, because its index is not kept fast or complete across the whole machine by default. A good full-text index answers the same question in microseconds.
How is a full-text index kept up to date?
A good one updates as files change instead of rebuilding from scratch. Interlinked makes a saved file searchable again in about a millisecond (under 30 ms in the worst case) so the index never drifts from what is actually on disk.
Do I still need grep if I have a full-text index?
Yes. grep stays perfect for one file, a pipe, or a quick regex in the folder you are already standing in. The index answers first on the whole-machine questions that would otherwise cost a full scan. They complement each other rather than compete.
Put a live index on your machine
Stop scanning your disk. Look it up.
Install once. One signed installer wires up 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest. No JSON to edit.
Let it read the disk once. Filename search works immediately; full-text content fills in behind it. From then on every search is a lookup instead of a walk: machine-wide, in the microsecond-to-millisecond range.
Keep grep for one file. It stays exactly where it is, still perfect for a single file or a pipe. The index just answers first on the questions that would otherwise cost a full scan.
Let it stay live. Save a file and it is searchable again in about a millisecond. At rest the whole engine sits around 44 MB and the index takes under 1% of the drive.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows.