Tokei: count code, comments and blank lines by language
Count your code, quickly.
At a glance
- What is it?
- Tokei is a Rust tool and library that reports files, code, comments and blank lines by language. It can also export statistics and combine a saved result with another run; available formats depend on the build.
- Who is it for?
- Tokei is useful for exploring the composition of a codebase, provided you understand its language classifications and ignore rules. Check the installed binary's supported output formats and test them before building automation.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 69 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.
Star history
- XAMPPRocky/tokei15,069 ★ · +137
| Repository | 2026-09-22 | 2026-11-14 |
|---|---|---|
| XAMPPRocky/tokei | 14.9k | 15.1k |
137 Stars in the last 53 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
Output formats and build features
Tokei normally prints a terminal report. Its README documents JSON, YAML and CBOR output through `--output`, and notes that serialization capabilities depend on build features. The documented source installation commands include `cargo install tokei --features all` or a specific `cbor` or `yaml` feature.
An unconditional dependency in Cargo.toml alone does not prove a particular output path is enabled. Check `tokei --help` and test the desired format with the exact package or binary you install; package maintainers may use different build features.
Combining saved results
The README documents `--input` for adding a previous result to a new run, for example `tokei ./foo --input ./stats.json`. It also describes reading from standard input. The saved result must be in a format supported by the installed build.
Adding successive snapshots of the same repository creates an accumulated sum, not a history of independent snapshots, and can count the same files repeatedly. Save separate timestamped results to compare changes over time; combine results only when an aggregate is intended.
Language definitions
Supported language definitions are maintained in `languages.json`, and the project links contribution instructions for adding and testing a language. The build includes language data and generates code from it.
A new definition may require more than an extension: comment rules, ambiguous file types and tests can matter. Follow the contribution guide and verify representative files rather than assuming a data edit alone always suffices.
Reading language totals
Tokei groups counts by its language definitions. The README example includes separate Bash and Shell rows; these represent separate reported categories and do not by themselves show that files were counted twice. Use `--files` to inspect individual classifications before combining categories for a report.
Performance and version differences
The README links a historical performance comparison. Results depend on the version, filesystem, file set, cache and hardware, so an older benchmark does not establish current rankings. Benchmark the installed version on a representative tree and record the command and ignore settings when comparing tools.
Licensing
The package manifest declares the SPDX expression `MIT OR Apache-2.0`, allowing use under either listed license subject to its terms. Review the license files for the version you distribute and check the terms of any separate dependencies.
Ignore rules
By default Tokei respects `.gitignore` and `.ignore` files; the README also documents `.tokeignore` and an `--exclude` option using gitignore-style patterns. `--no-ignore` disables several ignore layers, while narrower flags control parent, dot and version-control ignore files.
This does not mean the scanned file set always equals the files tracked by Git: hidden files and other filtering rules can differ. Check `--help`, use `--files`, and compare representative paths when an exact inventory matters.
Editorial conclusion
Tokei is useful for exploring the composition of a codebase, provided you understand its language classifications and ignore rules. Check the installed binary's supported output formats and test them before building automation. Counts are descriptive metrics rather than measures of code quality or developer productivity.
Frequently asked questions
how to install tokei
Through package managers on every major platform: the Alpine, Arch, Fedora, FreeBSD, NetBSD, openSUSE, Void and Nix package managers, Cargo, Conda, Homebrew and MacPorts on macOS, and two Windows package managers. Prebuilt binaries are in the releases section, and building from source needs the latest stable Rust compiler via a cargo install from the git repository. A small Alpine-based container image is also built through a tool called earthly.
how to use tokei
Pass one or more directories and it reports files, lines, code, comments and blanks per language. Options let you sort by any column, print per-file rather than per-language totals, exclude paths with ignore-file syntax, list the supported languages and their extensions, and include hidden files. By default it respects version control and generic ignore files, and it can also read a previous machine-readable result back in to combine runs.
What is a good rust tool to count lines of code?
Tokei is written in Rust and is presented as very fast, with a comparison linked from a version 11.0.0 release. It claims accuracy on the cases that separate good counters from bad ones, correctly handling multi-line comments, nested comments, and comments that sit inside strings rather than counting them. It supports over 150 languages and their extensions, and is also usable as a library.
Official sources
Was this useful?