r-lyeh/single_file_libs: a curated index of single-file C and C++ libraries

What r-lyeh/single_file_libs actually is

This is a list, and only a list. The top level of the repository holds a .github directory and README.md. There is no source tree, no build script, no package manifest and no test suite. Anyone expecting a library to clone and compile has misread the project.

The README states its purpose plainly: a list of small, easy-to-integrate, portable libraries usable from C and/or C++, compilable on 32-bit and 64-bit platforms, with a preference for libraries that are C, public domain and single-file. It also carries an unusual disclaimer for a curated list: the maintainers say they have not personally verified that any specific library is as advertised, or is quality software. That sentence changes how you should read every row in the main table.

The audience is narrow and specific. It is aimed at C and C++ developers, and the linked Discord server describes itself as a space for C, C++, library authoring and game development. If you are writing a game, a tool, or an embedded component and you want to drop a dependency into your tree instead of adding one to a package manager, this is the kind of index you want. If you are building a large application with a dependency policy, a list with no versions and no audit trail is the wrong starting point.

The submission rules and what they exclude

The README lists five rules for inclusion. Libraries must be usable from C or C++, ideally both. They must include the licensing terms in the header and source files. They should work on more than one platform, ideally all major desktops or all major mobile targets. They should compile on both 32-bit and 64-bit. And they should use at most two files, one header and one source, with more than two files mostly forbidden. The README adds that exceptions are allowed for good reasons.

That last clause matters. Because exceptions are permitted, the rule set describes an intent rather than a filter you can rely on. A library with three files can be in the list, and the README gives no marker for which entries are exceptions. The main table does carry per-entry metadata in parentheses: a file count, a language, and a license short name. The first row shown in the README is a C++ library tagged MIT with one file, and a later row shows a C library tagged PD with two files. The file count is the field to read first if the two-file limit is what you care about.

The license field is where the emphasis on clause-less licenses shows up. The README says single-header C files with clause-less licenses are highlighted, so the visual treatment of a row carries information that a plain text copy of the README loses. If you are reading the table through a mirror or a scraper, you may not see which entries were highlighted.

How the catalogue is organised

The main listing is a Markdown table with three columns: tag, library, and description. The tag column is a short subject label such as misc or 2d, and the README's excerpt shows several 2d entries in a row. The library column holds the name as a link to the upstream project, followed by the parenthesised metadata: file count, language, license. The description column is a one-line summary, sometimes with a size hint such as a line-of-code figure.

There is no alphabetical index, no per-tag table of contents, and no machine-readable export. Everything is prose and table rows in a single README. For a human browsing, that is fine. For anything automated, it means parsing Markdown and accepting that the parenthesised metadata is free-form text rather than structured fields.

The README also links a long list of other collections, including STB, clib, CCAN, cute_headers, dr_libs, klib, sokol, zpl and many more. That section is worth reading before you search the main table, because some categories are better covered by a dedicated collection than by this list.

Reading a row and moving to the upstream project

There is nothing to install. The README does not describe a package, a CLI, or a download step for the list itself, because the list is a document. The workflow is: read the table, follow the link in the library column, and take the files from the upstream repository.

The README does not document a canonical integration pattern for the libraries it lists, so every build detail, the header name, the define that enables the implementation, whether a separate source file exists at all, comes from the upstream project and not from this list. The README gives no per-library build instructions, and it names no specific library's files.

The only concrete artefact the list gives you is the row itself: the tag, the linked name, the file count, the language and the license short name. Everything after that is the upstream project's documentation.

The verification burden the README puts on you

The most important limitation is stated by the project itself. The README says the maintainers have not personally verified that any specific library is as advertised, or is quality software. A row in the table is a pointer, not an endorsement.

That has concrete consequences. The metadata in parentheses is reported, not checked, so a license short name in the table is not a substitute for reading the license text in the files. The two-file rule has exceptions, so a file count of three does not mean the entry is out of scope. Platform claims in the rules describe what entries should do, not what has been confirmed for each one.

There is also no versioning. The README gives no releases, no tags and no change history for the listed libraries. You cannot pin a row to a revision, and you cannot tell from the list whether an entry has been updated since it was added. If your project needs reproducible dependency resolution, this list cannot provide it, and you should not try to make it.

The practical failure mode is picking a library because it appears in the table and looks small, then discovering at integration time that it does not build on your compiler, or that its license text is missing from the source files despite the submission rules. Neither outcome is a defect in the list, because the list never claimed to have checked.

How it differs from STB, clib and other collections

The README itself points at alternatives, which makes the comparison easy to state. STB is described there as a collection of gamedev utilities. That is a single maintainer's set of libraries, so the quality bar and the coding style are consistent across entries. This list is the opposite: many authors, many styles, no shared standard beyond the submission rules.

clib is described as a list of mostly small single C functions with licenses not listed. That is a narrower unit of reuse, a function rather than a library, and the missing license field is the trade-off. This list's rules require licensing terms in the header and source files, which is a better starting point if license clarity is what you need.

CCAN is described as a package of shareable C functions with mixed licenses. The word package matters: CCAN is structured to be consumed as a package, while this list is a document you read. If you want something installable, the list is not it.

The honest summary is that this repository competes on breadth and on the license preference stated in its title emphasis, and it loses on verification, versioning and tooling to every alternative that actually ships code.

Maintenance, licensing and what the list costs you

The repository is not archived, and the last push was on 2026-08-18. That is recent enough that the list is being touched, and the README's invitation to open a pull request, an issue, or a message in the Discord channel is the maintenance model: contributions arrive from readers. There are no releases, so an update is a commit to README.md, and there is no changelog to tell you what changed between two reads.

The upgrade cost is therefore near zero for the list itself and potentially high for the libraries it points at. Nothing in the repository tracks upstream versions, so a library you vendored can drift from what the table describes without the table changing.

On licensing, no license is given for the catalogue text itself. The licenses that matter are the ones on the individual libraries, and the README's preference for clause-less licenses is a preference, not a guarantee: the excerpt shows entries tagged MIT, ISC, WTFPL2, CeCILL and PD, and CeCILL is a copyleft-style French license rather than a permissive one. The submission rule requires the license terms to appear in the header and source files, so the file itself is the authoritative source. Read it there. This is not legal advice, and a short license tag in a table is not a substitute for the text.

Editorial conclusion

Adopt this list if you want to find a small C or C++ library you can vendor as one header plus one source file, and you are willing to check each candidate's license and platform claims yourself. Do not adopt it if you expect a package manager, a versioned release, or a guarantee that any listed library compiles on your target. Before you pick anything, open the library's own repository and confirm three things: that the license text is present in the header and source files, that it names the platforms you need, and that it builds on both 32-bit and 64-bit as the list's rules require. The list itself is only a README, so the verification burden sits entirely with you.

Frequently asked questions

Official sources

1. Issues
2. README
3. r-lyeh/single_file_libs on GitHub