Comparisons · measured July 2026 · 7 min
fzf finds. ripgrep searches. They aren't rivals.
If you search code for a living, you use both, often in the same breath. fzf is a fuzzy finder: type a loose fragment of a filename and it surfaces the file. ripgrep is a content searcher: hand it a string or a pattern and it finds every line inside your files that matches. Two different questions, one common pairing, and one quiet cost they both carry: on a big enough drive, both walk it on every query.
TL;DR · the short version
The finder, the searcher, and the layer under both.
Not rivals: teammates. fzf is a fuzzy finder (search by name); ripgrep is a content searcher (search by text). Different questions. fzf.vim's :Rg command even pipes ripgrep straight into fzf.
One shared blind spot: the walk. Reach past the current folder and both pay for the whole drive on every query. On 4.47M files, a single ripgrep content query took 93.8 s; feeding fzf every filename means an enumerator walk of the same shape.
The walk can happen once. A prebuilt, always-fresh index answers names in 85 µs and content in ~7 to 9 ms (about 58,625× faster than ripgrep's 93.8 s on average) across that same 4.47M-file machine.
A layer, not a replacement. Keep fzf and ripgrep for the repo and the pipe; the index just answers first when the file or the string lives anywhere else on the machine, and every AI client gets the same reach.
Cheap and always current. About 44 MB at rest, under 1% of the drive on disk, searchable ~1 ms after you save. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.
The division of labour, drawn plainly
Two questions. One shared blind spot.
The confusion is understandable: they live in the same terminal and both make files appear. But they operate on different things. fzf matches your query against a list of names, keeping any where your letters appear in order (a subsequence), then ranks the closest. It never opens a file. ripgrep does the opposite: it opens files and scans their contents for a literal string or a regular expression, and it doesn't care what the file is called.
Drawn side by side, the split is clean: fzf owns the name column, ripgrep owns the content column, and the cost they both pay sits underneath both of them.
Read left-to-right: fzf lights the name column, ripgrep lights the content column, and only a pre-built index spans both without walking the disk. Whole-machine query times: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files.
Both are excellent · both are worth keeping
Meet the finder and the searcher.
Neither tool is trying to be the other. Once you see what each was built for, the “which should I use” question mostly dissolves: the answer is usually both.
fzf filters a list interactively as you type. It doesn't crawl anything itself: you pipe a list in (fd, find, git ls-files, your shell history) and it fuzzy-matches against it, narrowing per keystroke. That composability is the point: it turned fuzzy selection into a Unix primitive you can bolt onto anything.
ripgrep recursively searches file contents for a pattern. It fans the walk across every core, respects your .gitignore, skips hidden and binary files by default, and uses a regex engine that can't catastrophically backtrack. It's the fastest content searcher there is, and it's what runs under find-in-files in most editors.
They're teammates, not rivals. fzf.vim's :Rg command literally pipes ripgrep's output into fzf: the searcher feeds the finder, and you get interactive content search with a live preview. Reach for fzf when you know roughly what the file is called; reach for ripgrep when you know a string that's inside it. The trouble only starts when the answer isn't in the folder you're standing in.
Why the wall exists
Both are fast. Both still walk.
Here is what they have in common, and it is the part that bites at scale. ripgrep's speed comes from walking the directory tree efficiently, but it still opens, reads, and closes every non-ignored file on every query. fzf's matching is instant, but the list it matches has to come from somewhere; reach past the current folder to the whole machine and something (fd, find) has to walk the disk to produce it. Either way, the cost scales with the size of the drive, not the size of your question.
On our 4.47-million-file volume, one content query took ripgrep 93.8 seconds. Point an enumerator at the same volume to feed fzf and you pay a walk of the same shape. Neither tool is doing anything wrong: they were built to walk, and they walk well. The ceiling is the walk itself, and it is the same wall for the finder and the searcher.
fzf can't tell you which files say “deprecated”; ripgrep can't rank the file whose name you half-remember. Different questions, or one layer that answers both.
Whole-machine reach means re-walking the disk every query, whether it's fd feeding fzf or ripgrep reading bytes. The bigger the machine, the slower it gets.
Nothing says names and contents have to be scanned at query time. Do it once, keep it fresh as files change, and both questions become a lookup.
Same machine · same drive
The same two questions, across 4.47 million files.
Point each tool at the whole machine and the walk shows up in the numbers. ripgrep's content query took 93.8 seconds; fzf's own matching is instant, but feeding it every filename means an enumerator walk that grows with the drive. A purpose-built index answered the name query in 85 microseconds and the content query in 16 milliseconds, the same string, the same corpus.
| The tool | Answers | What it matches | Whole-machine query | vs Interlinked |
|---|---|---|---|---|
| Interlinked | both | fuzzy names + literal/regex content, one index | 85 µs · 16 ms | 1× (baseline) |
| ripgrep (rg) | by content | literal / regex inside files, parallel walk | 93.8 s | 58,625× * |
| fzf + fd / find | by name | fuzzy filename over a piped, walked list | walk-bound * | n/a |
| grep -r | by content | literal / regex, single-thread walk | slower still | n/a |
Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files. * ripgrep with default settings (.gitignore respected): 93.8 s is one query in a five-query content set; across the set the gap averaged 58,625×, with Interlinked content search at ~7 to 9 ms typical. fzf's matching is instant: the cost is the enumerator (fd / find) walking the disk, so its whole-machine time is bound by that walk. Interlinked name lookup: 85 µs single file, 139 µs median of 20 queries, 2 µs best case. More in the ripgrep content comparison and what fuzzy finding is.
One index · both questions
Keep both tools. Drop the walk.
Interlinked keeps one always-fresh index of every filename and every file's contents on the machine (across every repo and the non-git 90%) and answers both questions out of it. Loose, ranked name queries in the microsecond range; content queries in a few milliseconds. No workspace to open, no list to enumerate, no tree to crawl: the walk already happened, in the background, and the index stays current as files change. And because it speaks the same protocol every AI client uses, your coding agent gets the same instant reach, not just you.
85 µs for a filename, ~7 to 9 ms typical for a content query: the fuzzy-find feel of fzf and the content reach of ripgrep, both without the walk, across 4.47M files. 19 AI clients wired up in one install, and nothing leaves the machine: there is no model anywhere in the box.
NOT A REPLACEMENT FOR fzf OR ripgrep: THE INDEXED LAYER THAT ANSWERS BOTH QUESTIONS AT ONCE.
FAQ · common questions
Common questions, answered plainly.
The short answers to what people ask after seeing the numbers.
QShould I stop using fzf and ripgrep?
No. They're excellent at what they do: fzf for fuzzy-finding a filename, ripgrep for scanning content in a repo or a pipe. Interlinked is a layer on top, not a replacement; it just answers first when the file or the string lives outside the folder you're standing in.
QWhy is it so much faster?
fzf and ripgrep walk the disk on every whole-machine query, so their cost scales with the size of the drive. Interlinked walks once in the background and keeps the index fresh, so every query after is a lookup: names in 85 µs, content in ~7 to 9 ms, versus ripgrep's 93.8 s for one content query across 4.47M files.
QDoes it search filenames or the text inside files?
Both, from one index. It answers fuzzy name queries (fzf's job) and literal or regex content queries (ripgrep's job) across every repo, and the non-git files a cwd search quietly misses.
QWill the index stay current as I edit?
Yes. Save or rename a file and it's searchable again, by name and by content, in about a millisecond (under 30 ms in the worst case, with no re-scan). At rest the engine sits around 44 MB and the index takes under 1% of the drive.
QWhat does it cost?
Everything (including the MCP layer that gives Claude Code, Cursor, Codex and 16 other clients the same instant reach) is free forever, on all your devices, no card. Hosting starts at $5.99/mo.
Keep your tools
Keep fzf. Keep ripgrep.
Install once. One signed installer wires up 19 AI clients (Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest) and starts indexing every filename and its contents on the machine. No JSON to edit.
Keep your tools. fzf and ripgrep stay exactly where they are, perfect in a repo and a pipe. The index just answers first when the file, or the string, lives anywhere else on the machine.
Let it stay fresh. Save or rename a file and it's searchable again (by name and by content) in about a millisecond. At rest the engine sits around 44 MB and the index takes under 1% of the drive.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows · ripgrep vs grep, measured