tlrc: the official tldr client, written in Rust

A client for a repository of community examples

tlrc is the official tldr client written in Rust, and it fetches the pages from the tldr-pages project on GitHub. The tldr pages themselves are a collection of short, example-driven descriptions of command line tools, maintained by volunteers in many languages, and this client is what puts them in a terminal.

The project description is one line, and the README is mostly about installation and configuration, which tells you where the interesting decisions were made. The choice of Rust is visible in the distribution story, since a single static binary is what makes the same binary work on a Mac, a Windows box and a NetBSD machine, and it is what allows the project to publish prebuilt binaries and Debian packages alongside the crates.io package.

The client is MIT licensed, and the repository carries the usual set of badges for the CI workflow, the latest release, the crates.io version, the licence, the download count and a Matrix room for the tldr-pages community.

The release history is steady rather than dramatic, with v1.13.1 in May 2026, v1.13.0 in March 2026 and v1.12.0 in September 2025, and the last push was on 2026-10-01. That cadence suits a client whose job is to keep working while the pages behind it change.

Twelve ways to install, and the one that loses the man page

The installation section is the longest part of the README, and it is a good proxy for how the project thinks about its users. The same binary is available through Homebrew with brew install tlrc, from Nix, from the AUR on Arch with a source package and a prebuilt one, through XBPS on Void Linux, through Zypper on openSUSE, through Winget on Windows with winget install tldr-pages.tlrc, through Scoop, through MacPorts with port install tlrc, through pkgin on NetBSD, through Conda with conda install conda-forge::tlrc, and of course from crates.io.

The crates.io route is the one with a caveat, and the README is explicit about it:

cargo install tlrc --locked

with a note that shell completion files and the man page will not be installed that way. That is a packaging consequence rather than a defect, and it is the only one mentioned.

The GitHub Releases page is the alternative for the pieces that cargo does not install, with prebuilt binaries and Debian packages.

For a Linux or macOS user the choice is Homebrew or Nix, for a Windows user it is Winget or Scoop, and for a system that manages its own packages the Repology badge at the top of the section shows where else it has been packaged.

The cache, the mirror, and a checksum contract

The configuration is TOML, and the file is found by asking the client where it keeps it:

tldr --config-path

A default one can be generated straight into that path, which is a nicer approach than writing a config by hand and wondering whether the client is reading it:

tldr --gen-config > "$(tldr --config-path)"

The cache section is where the interesting constraint sits. The directory can be overridden, with a tilde expanded to the home directory. The mirror can be set to a base URL for downloading the pages, and the comment sets out the contract precisely: the mirror must provide files with the same names as the official tldr pages repository. It must provide tldr.sha256sums, which has to point to the SHA256 checksums of all assets, and it must provide tldr-pages.LANGUAGE.zip, which has to point to a zip archive containing platform directories with pages in that language. The default mirror points at the GitHub releases of the tldr-pages repository.

That contract is a security property rather than a formality. A mirror is a third party serving content that your terminal will render, and the checksums file is what lets the client verify what it downloaded. A mirror that omits the sums file is not usable, and a mirror whose sums do not match is a problem the client is designed to catch.

Automatic updating is on by default, with max_age set to 336 hours, which is two weeks, and a defer_auto_update option that moves the update to after the page is shown rather than before it, so a first run does not wait for a download.

Languages, and how the page list is chosen

The languages list is short to configure and has a sensible default. If it is empty, the languages specified in the LANG and LANGUAGE environment variables are downloaded, and English is implied and will always be downloaded.

That default is the right one for a tool that people run on whatever machine they are logged into, because a German user in a German locale gets German pages without configuring anything, and an English page is always there for a command whose translation does not exist.

The output section is where the client stops being a plain renderer and starts being a tool you tune. There is show_title to show the title of the page and platform_title to show the platform name, common or linux or osx, in that title. show_hyphens prefixes descriptions of examples with hyphens, and example_prefix replaces that hyphen with a custom string.

line_length sets the maximum line length, with 0 meaning use the terminal width, and a longer description is split into multiple lines when the limit is set. compact strips empty lines from the output. raw_markdown prints the page as raw markdown rather than rendering it.

The option_style option is the one that surprises people. In option placeholders, the style can show the short form, the long form or both, so a page that documents an option as {{[-s|--long]}} can be rendered as -s, as --long, or as [-s|--long]. The default is long, and a team that writes a wrapper script around the client will want to know that this is a per-user setting rather than a property of the page.

Styling, and the layout knobs under it

The final part of the configuration is the styling, and it is more capable than a colour setting.

Each style section takes a colour, which can be a fixed name such as black, red, green, yellow, blue, magenta, cyan, white, default, and the bright variants, a 256-colour ANSI code written as { color256 = 50 }, an RGB triple as { rgb = [0, 255, 255] }, or a hex string as { hex = "#ffffff" }. Alongside the colour there are the usual attributes, bold, underline, italic, dim and strikethrough, and a background colour.

The indent section is a separate thing and is easy to miss. It sets the number of spaces before each kind of line: 2 for the title, 2 for the description, 2 for the description bullets and 4 for the example invocations. That last number is the one people change, because the indented example commands are the part that runs off the edge of a narrow terminal.

Together, the two sections mean a client that fits a house style rather than one that prints a fixed layout. The default title style is magenta and bold, and the description style is magenta without the bold.

Where tlrc is the wrong choice

The first wrong-tool case is treating the pages as documentation. They are examples, written by volunteers, and they show the common invocations of a command rather than its complete behaviour or its options. For a man page, a package's own help output or the upstream documentation is the authority, and tlrc is the thing you read when you already know what you are looking for.

The second is a machine with no network and no cached pages. The client downloads the pages it shows, and the cache is a cache, so an air-gapped host needs the pages provisioned in advance or a local mirror. The mirror configuration makes that possible, but it is work the user has to do.

The third is a team that wants the pages in a different format. The output options cover the terminal rendering, the layout and the raw markdown, and that is the end of it. There is no JSON output for a script to consume, which is the usual request once a project starts using the client in automation rather than by hand.

The fourth is a user who has the official client already. The README does not say the official client lacks features, and the point is only that this one is packaged more widely, so the reason to choose it is distribution rather than function.

Editorial conclusion

Adopt tlrc if you want the tldr pages on a machine where the official client is awkward to install, since it packages cleanly everywhere from Homebrew to Nix to winget, and use it with the generated default configuration to start. Do not adopt it as a documentation system, since the pages are community examples and not a reference, and do not expect the man page and shell completions to arrive with a cargo install, because the README says they are not installed that way. Before you point it at a mirror, read the checksum contract in the cache section, since a mirror has to serve the sums file and the language archives with the expected names.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tldr-pages/tlrc on GitHub