Explainers · the everyday feature, demystified · 7 min
How does Ctrl+F actually work? It only reads one page.
Press Ctrl+F (or Cmd+F on a Mac) and that little bar appears. You type a word, every copy of it lights up, and Enter walks you through them. It feels instant because it is: your browser or editor is scanning the text of the one document already open in front of you, top to bottom, and nothing else. It never touches your hard drive, your other tabs, or your files. That single fact (it only reads what is already loaded) is the whole reason Ctrl+F is fast, and the exact reason it can't search your computer.
TL;DR · the short version
Ctrl+F only reads the one document already open. It scans the page or file in front of you (text already sitting in memory) from top to bottom. That is why it feels instant, and exactly why it cannot search the rest of your computer.
Point the same scan at a whole drive and it breaks. 4.47M files sit on disk, none of them loaded, so answering means opening and reading every one on every query. VS Code's cross-file search takes 35 s; Windows Search takes about 67 s.
An index flips the bargain: read the drive once, then every search is a lookup. Finding a file by name takes 85 µs (a 139 µs median across 4.47M files), 412,000× faster than VS Code and about 480,000× faster than Windows Search.
Searching inside every file runs in 7 to 9 ms. The same content query where ripgrep took 93.8 s finished in 16 ms (58,625× faster), and an agent task of 71 back-to-back searches collapses into a single lookup.
It stays fresh and stays small. A saved file is searchable again in about a millisecond, and the whole engine sits around 44 MB at rest. Keep Ctrl+F for the page in front of you; use the index for the whole machine.
What happens when you press the keys
It scans text it already has. That's the whole trick.
When you hit the shortcut, the app opens its find bar and starts searching as you type, letter by letter, re-running the match live. It isn't reaching out to anything. It is looking through the text it is already holding in memory: the rendered words of the web page, or the contents of the file you have open. A fast string-matching routine (the kind computer science settled on decades ago) finds every occurrence, highlights them, and keeps the running count you know as 3 of 7. Enter, or the down arrow, jumps to the next hit.
It feels instant because the haystack is tiny and close at hand. A web page or a source file is kilobytes to a few megabytes, and it is sitting in RAM the moment you press the keys. Scanning that once is a blink: no disk to spin, no network to wait on. The two most famous places you do this prove the pattern: in a browser, Ctrl+F searches the page you are looking at; in VS Code, Ctrl+F searches the file you are looking at. Same idea, same speed, same hard limit: one document.
Other tabs, history, downloads. It searches this page, not the last one, not your bookmarks, not a file on disk.
Text that hasn't rendered yet. On a long, lazy-loaded page, or inside a collapsed section, if it isn't in memory, Ctrl+F won't find it.
A single file on your machine. It reads what is already loaded. Nothing is opened, nothing is read off the disk.
The whole idea in one picture
One document is easy. A whole drive is a different problem.
Ctrl+F is fast for one reason: its haystack is a single small thing already in memory. Change nothing about the method but point it at your whole machine, and every one of those assumptions breaks at once. The files aren't loaded. There are millions of them. And they live on a disk that has to be read before anything can be scanned. Here is the same search, drawn at both scales.
Left: Ctrl+F reads one page top to bottom, in memory, and lands both matches in a blink. Right: the same instinct at drive scale, 4.47M files that must each be opened off disk before they can be scanned, on every query. A scan of the drive takes 35 seconds; a lookup against a live index takes 85 microseconds. Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files.
The moment one document becomes many files
Watch where the two tools you know quietly hand off.
In a browser, Ctrl+F stops at the edge of the page. Want to search across everything you have open, or every site you visited this week? Ctrl+F has nothing to offer: it was only ever built for the document in front of you. That isn't a flaw; it is the design.
VS Code makes the hand-off visible, because it ships two different searches. Ctrl+F is the in-memory scan you just met: the open file, instant. Ctrl+Shift+F, “search across files,” is a completely different animal: it walks the folder, opening files off the disk one at a time. VS Code doesn't even do that part itself: it runs ripgrep, a command-line searcher, under the hood. It is a separate keystroke for a reason: it is a separate cost class.
And the cost shows. On our test machine (4.47 million files across a dozen repos plus everything that was never in git), VS Code's file search takes 35 seconds. Same keystroke family, but scanning many files off a disk is not scanning one page in memory. We timed every editor the same way in the VS Code write-up.
Why a bigger box doesn't fix it
You cannot Ctrl+F a hard drive.
The instinct is to imagine Ctrl+F with a bigger box: point it at the whole disk and let it rip. It can't work, and the reason is physical, not lazy engineering. Ctrl+F is fast because its haystack is already in memory. Your 4.47 million files are not; they sit on the disk. To scan them the way Ctrl+F scans a page, something has to open and read all of them first, and that reading is the 35 seconds, or the 67 seconds, every single time you ask.
Editors punt to a slower cross-file search. The operating system indexes only a slice and walks the rest. Your AI coding agent (Claude Code, Cursor, Copilot) shells out to the very same walk, dozens of times a session. The scan was never the wrong tool for one document. It is simply the wrong tool for a machine, and the only real way out is to stop scanning on demand: do the reading once, ahead of time, and remember it. That is an index.
Do the reading once
Read the drive once. Then every search is a lookup.
An index flips the bargain. Instead of reading files at the moment you ask, a quiet background service crosses the machine one time and keeps a compact, live map of every filename and everything inside every file. It stays fresh on its own: save a file and it is searchable again in about a millisecond. After that, a search is not a scan at all. It is a lookup, the same way Ctrl+F never re-reads a page it already holds. The gap between a scan and a lookup is the gap between 35 seconds and 85 microseconds.
An index sounds heavy until you weigh it. The whole engine sits around 44 MB at rest (less than a single browser tab), and takes under 1% of the drive (about 24 GB on a 4 TB machine). The same live index also remembers the short notes any agent leaves on a file, so the next one picks up where the last stopped. Keep Ctrl+F for the page in front of you. For everything else, give the machine a search that already did the reading.
Common questions
The questions Ctrl+F raises. Answered.
QWhy can't I just Ctrl+F my whole computer?
Ctrl+F only searches the one document already loaded in memory, the page or file in front of you. The rest of your files (4.47 million of them on our test machine) live on disk and are not loaded, so searching them that way means opening and reading every file on every query. That takes seconds to minutes, not the blink you are used to.
QWhat's the difference between Ctrl+F and Ctrl+Shift+F in VS Code?
Ctrl+F is the in-memory scan of the file you have open, and it is instant. Ctrl+Shift+F (“search across files”) is a different cost class: it shells out to ripgrep and walks the folder, opening files off disk one at a time. On our 4.47M-file drive that took 35 seconds.
QHow can a prebuilt index be hundreds of thousands of times faster?
It never re-reads your files at search time. A background service reads the drive once and keeps a compact, live map of every filename and every file's contents, so a search becomes a lookup instead of a scan. Finding a file by name takes 85 µs, 412,000× faster than VS Code and about 480,000× faster than Windows Search's 67 seconds.
QDoes keeping a live index slow down my computer?
No. The whole engine sits around 44 MB at rest (less than a single browser tab), and it stays fresh on its own, making a saved file searchable again in about a millisecond. Searching the text inside every file runs in 7 to 9 ms; the same query where ripgrep took 93.8 seconds finished in 16 ms.
QWhat does this mean for AI coding agents, and what does it cost?
Agents like Claude Code, Cursor and Copilot answer “where is X?” by shelling out to the same disk walk dozens of times a session. One task that took an agent 6 min 57 s across 71 tool calls becomes a single 16 ms lookup. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.
Keep Ctrl+F. Add a floor under it.
Give your machine a search that already read the disk.
Install once. One signed installer wires up 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest. No JSON to edit.
Keep Ctrl+F exactly where it is. It stays perfect for the one page or file in front of you. The index handles the other question (the whole machine) in the microsecond-to-millisecond range.
Let it stay fresh. Save a file and it's searchable again in about a millisecond. At rest the whole engine sits around 44 MB and the index takes under 1% of the drive.
Scope when you know where you are. Whole-machine when you don't know where something lives; scoped to a folder when you do. Either way, a lookup, not a scan.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.