# ripgrep vs fd: source lines of code compared

The ripgrep vs fd comparison on OctoCounts shows side-by-side source line counts for BurntSushi/ripgrep and sharkdp/fd, counted with the same engine and analysis options on the dates shown in the methodology line: files, total lines, code lines, comment lines, blank lines, and per-language totals, pinned to the exact commits listed below.

As of 2026-09-06, BurntSushi/ripgrep contains 46,567 total lines (35,349 code) across 128 files, while sharkdp/fd contains 6,903 total lines (4,300 code) across 36 files as of 2026-09-16. BurntSushi/ripgrep is about 8.2x the size of sharkdp/fd by code lines. Code size is not code quality: a larger count only means more source material, not a better or worse project.

| Metric | [BurntSushi/ripgrep](https://octocounts.com/github/BurntSushi/ripgrep) | [sharkdp/fd](https://octocounts.com/github/sharkdp/fd) |
| --- | ---: | ---: |
| Files | 128 | 36 |
| Total lines | 46,567 | 6,903 |
| Code lines | 35,349 | 4,300 |
| Comment lines | 6,267 | 1,433 |
| Blank lines | 4,951 | 1,170 |
| Languages counted | 10 | 8 |

Top languages in BurntSushi/ripgrep: Rust (92.4% of code), Python (3.2% of code), YAML (1.8% of code). Top languages in sharkdp/fd: Rust (92.2% of code), Shell (3.6% of code), TOML (2.2% of code). Rust, TOML appear in both top language lists; Python, YAML, Zsh appear only in BurntSushi/ripgrep's top languages; Shell, Makefile, AWK appear only in sharkdp/fd's top languages.

Methodology: both counts come from cached OctoCounts reports generated with tokei. BurntSushi/ripgrep was counted at ref c1fc6a5eb8c971fc43041d3df34cf8bd49f31032 (commit c1fc6a5eb8c9) on 2026-09-06; sharkdp/fd was counted at ref 5bbfa3eb1d1f3df78b9def10ea1c074307f9f22e (commit 5bbfa3eb1d1f) on 2026-09-16. See the [counting methodology](https://octocounts.com/docs/methodology) for ignored directories and analysis options.
## About this comparison

BurntSushi/ripgrep counts the ripgrep repository: the line-oriented search tool written in Rust, with its supporting crates for regex handling and its test corpora. sharkdp/fd counts the fd repository: the file-finding tool, also written in Rust. Both are single-purpose command-line tools, making this one of the cleaner like-for-like comparisons on the site, counted on the dates in the methodology line.

Both codebases are Rust-dominant in the per-language tables, so the difference in totals reflects what each tool takes on rather than how it is written: ripgrep carries its own search and regex machinery in-tree, while fd builds on shared crate dependencies for directory traversal and ignore-file handling.

Each repository includes completion scripts, documentation, and substantial test fixtures — in ripgrep's case including corpora that keep its matching correct — so part of each count exists to package and verify the tool rather than to run the search itself.

_The totals do not measure search speed or memory use in your working directory; those depend on the query, the file set, and the installed versions. A smaller or larger repository here says nothing about which finds files faster._

Sources: [BurntSushi/ripgrep repository](https://github.com/BurntSushi/ripgrep) · [sharkdp/fd repository](https://github.com/sharkdp/fd). Statements verified 2026-09-16.

Evidence and next steps:

- [BurntSushi/ripgrep SLOC report](https://octocounts.com/github/BurntSushi/ripgrep)
- [sharkdp/fd SLOC report](https://octocounts.com/github/sharkdp/fd)
- [Compare BurntSushi/ripgrep and sharkdp/fd interactively](https://octocounts.com/compare?left=https%3A%2F%2Fgithub.com%2FBurntSushi%2Fripgrep&right=https%3A%2F%2Fgithub.com%2Fsharkdp%2Ffd)

Note: code size is not code quality. OctoCounts only reports reproducible line counts and makes no claim that either project is better.

## Compare FAQ

### Which has more lines of code, BurntSushi/ripgrep or sharkdp/fd?

BurntSushi/ripgrep has more code: 35,349 code lines versus 4,300 for sharkdp/fd, about 8.2x as much, based on cached OctoCounts reports as of 2026-09-16.

### Does more source lines of code mean more complexity?

Not necessarily. SLOC measures size, not complexity, quality, or maintainability. A larger codebase can mean more features, more generated or vendored code, more verbose language idioms, or more tests — none of which imply the code is harder to work with. Use SLOC to gauge the scale of what you'd be reading or maintaining, not as a quality signal for BurntSushi/ripgrep, sharkdp/fd, or any repository.

### How is this comparison calculated?

Methodology: both counts come from cached OctoCounts reports generated with tokei. BurntSushi/ripgrep was counted at ref c1fc6a5eb8c971fc43041d3df34cf8bd49f31032 (commit c1fc6a5eb8c9) on 2026-09-06; sharkdp/fd was counted at ref 5bbfa3eb1d1f3df78b9def10ea1c074307f9f22e (commit 5bbfa3eb1d1f) on 2026-09-16. See the counting methodology for ignored directories and analysis options.

### Can I compare a different branch, tag, or commit?

Yes. This page shows the default branch for each repository. Use the interactive comparison tool to pick any public GitHub repository, branch, tag, or commit SHA for both sides and get a fresh side-by-side report.

## Related OctoCounts pages

- [Interactive repository comparison](https://octocounts.com/compare)
- [Recently analyzed repositories](https://octocounts.com/recent)
- [Popular SLOC reports](https://octocounts.com/popular)
- [Trending GitHub repositories](https://octocounts.com/trending)
- [Hall of Monoliths](https://octocounts.com/hall-of-monoliths)
- [Original research: how filtering changes SLOC counts](https://octocounts.com/research)
- [GitHub SLOC counter guide](https://octocounts.com/docs/github-sloc-counter)
- [Counting methodology](https://octocounts.com/docs/methodology)
- [SLOC and code metrics glossary](https://octocounts.com/docs/glossary)
- [OctoCounts API docs](https://octocounts.com/docs/api)