grep vs ripgrep: Is It Worth Switching?
grep is everywhere; ripgrep is dramatically faster on code and respects .gitignore by default.
Side by side
| grep | ripgrep (rg) | |
|---|---|---|
| Installed by default | Yes, on every Unix system | No, needs installing |
| Speed on a large repo | Slow unless you exclude directories | Very fast, parallel by default |
| Respects .gitignore | No | Yes, automatically |
| Skips binary files | No, warns about them | Yes, automatically |
| Recursive by default | No, needs -r | Yes |
| Filter by file type | --include="*.py" | -t py (built-in type definitions) |
| Regex engine | POSIX BRE/ERE, backreferences | Rust regex — no backreferences, linear time |
| Output | Plain by default | Coloured and grouped by file |
| Typical command | grep -rn "text" . | rg text |
Which one, when
Searching a codebase on your own machine
Use ripgrep
Ignores dependency directories automatically, colours the output and finishes before you notice. The default command is also two words shorter.
$ rg "DATABASE_URL" On a server you just SSHed into
Use grep
It is already there. Installing tools on production machines to run one search is not a trade anyone should make.
$ grep -rn "timeout" /etc/nginx/ Filtering the output of another command
Use grep
Both work in pipes, but grep is the reflex and the universal one. This is the case where switching buys you nothing.
$ ps aux | grep nginx You need a backreference in the pattern
Use grep
ripgrep's regex engine deliberately excludes backreferences to guarantee linear-time matching. For those patterns grep -E (or perl) is the tool.
$ grep -E "(\w+) \1" file.txt Searching only one language's files
Use ripgrep
Built-in type definitions beat writing include patterns by hand, and they are correct for extensions you would forget.
$ rg -t py "def process" Gotchas worth knowing
- ripgrep skipping .gitignored files is usually what you want — but if you are looking for something in build output or logs, it will silently find nothing. Add -u to include ignored files, -uu to include hidden ones too.
- grep is not slow by nature; it is slow because it dutifully scans node_modules. Excluding directories closes most of the gap.
- Scripts should use grep for portability. A script that depends on rg breaks on any machine where it is not installed.
- The two disagree on regex dialects at the edges. Patterns with backreferences or POSIX classes may need adjusting.
- ripgrep is one binary with no dependencies, which makes it easy to drop onto a machine when you genuinely need it.
Frequently asked questions
How much faster is ripgrep really?
On a large repository with dependencies, often ten times or more — most of the win comes from not searching files it should ignore, not from raw scanning speed.
Should I alias grep to rg?
No. They differ in defaults and dialect, and scripts calling grep would break in confusing ways. Keep them as separate commands.
Are there other alternatives?
ag (the silver searcher) and ack came first and work similarly; ripgrep is generally the fastest of the three and the most actively maintained.
Does ripgrep work in pipes?
Yes, exactly like grep. In practice most people still type grep for piped filtering out of habit, and that is fine.
Full guides for both
Find lines matching a pattern in files or piped input — the workhorse of text search.
findLocate files anywhere in a directory tree by name, type, size, date — and act on them.
Put it into practice
Other comparisons
Both copy files over SSH. rsync sends only what changed; scp sends everything, every time.
curl vs wgetcurl is an HTTP client for talking to services; wget is a downloader for retrieving files.
sed vs awksed edits lines; awk understands columns. Substitution is sed, computation is awk.
symbolic link vs hard linkA symlink stores a path and can break; a hard link is a second real name for the same file.