stb

single-file public domain (or MIT licensed) libraries for C/C++

Noteworthy:

• image loader: stb_image.h
• image writer: stb_image_write.h
• image resizer: stb_image_resize.h
• font text rasterizer: stb_truetype.h
• typesafe containers: stb_ds.h

Most libraries by stb, except: stb_dxt by Fabian "ryg" Giesen, stb_image_resize by Jorge L. "VinoBS" Rodriguez, and stb_sprintf by Jeff Roberts.

library	lastest version	category	LoC	description
stb_vorbis.c	1.22	audio	5584	decode ogg vorbis files from file/memory to float/16-bit signed output
stb_hexwave.h	0.5	audio	680	audio waveform synthesizer
stb_image.h	2.27x	graphics	7901	image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC
stb_truetype.h	1.26	graphics	5084	parse, decode, and rasterize characters from truetype fonts
stb_image_write.h	1.16	graphics	1724	image writing to disk: PNG, TGA, BMP
stb_image_resize.h	0.97	graphics	2634	resize images larger/smaller with good quality
stb_rect_pack.h	1.01	graphics	623	simple 2D rectangle packer with decent quality
stb_perlin.h	0.5	graphics	428	perlin's revised simplex noise w/ different seeds
stb_ds.h	0.67	utility	1897	typesafe dynamic array and hash tables for C, will compile in C++
stb_sprintf.h	1.10	utility	1906	fast sprintf, snprintf for C/C++
stb_textedit.h	1.14	user interface	1429	guts of a text editor for games etc implementing them from scratch
stb_voxel_render.h	0.89	3D graphics	3807	Minecraft-esque voxel rendering "engine" with many more features
stb_dxt.h	1.12	3D graphics	719	Fabian "ryg" Giesen's real-time DXT compressor
stb_easy_font.h	1.1	3D graphics	305	quick-and-dirty easy-to-deploy bitmap font for printing frame rate, etc
stb_tilemap_editor.h	0.42	game dev	4187	embeddable tilemap editor
stb_herringbone_wa...	0.7	game dev	1221	herringbone Wang tile map generator
stb_c_lexer.h	0.12	parsing	940	simplify writing parsers for C-like languages
stb_divide.h	0.94	math	433	more useful 32-bit modulus e.g. "euclidean divide"
stb_connected_comp...	0.96	misc	1049	incrementally compute reachability on grids
stb_leakcheck.h	0.6	misc	194	quick-and-dirty malloc/free leak-checking
stb_include.h	0.02	misc	295	implement recursive #include support, particularly for GLSL

Total libraries: 21 Total lines of C code: 43040

FAQ

What's the license?

These libraries are in the public domain. You can do anything you want with them. You have no legal obligation to do anything else, although I appreciate attribution.

They are also licensed under the MIT open source license, if you have lawyers who are unhappy with public domain. Every source file includes an explicit dual-license for you to choose from.

How do I use these libraries?

The idea behind single-header file libraries is that they're easy to distribute and deploy because all the code is contained in a single file. By default, the .h files in here act as their own header files, i.e. they declare the functions contained in the file but don't actually result in any code getting compiled.

So in addition, you should select exactly one C/C++ source file that actually instantiates the code, preferably a file you're not editing frequently. This file should define a specific macro (this is documented per-library) to actually enable the function definitions. For example, to use stb_image, you should have exactly one C/C++ file that doesn't include stb_image.h regularly, but instead does

#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"

The right macro to define is pointed out right at the top of each of these libraries.

Are there other single-file public-domain/open source libraries with minimal dependencies out there?

Yes.

If I wrap an stb library in a new library, does the new library have to be public domain/MIT?

No, because it's public domain you can freely relicense it to whatever license your new library wants to be.

What's the deal with SSE support in GCC-based compilers?

stb_image will either use SSE2 (if you compile with -msse2) or will not use any SIMD at all, rather than trying to detect the processor at runtime and handle it correctly. As I understand it, the approved path in GCC for runtime-detection require you to use multiple source files, one for each CPU configuration. Because stb_image is a header-file library that compiles in only one source file, there's no approved way to build both an SSE-enabled and a non-SSE-enabled variation.

While we've tried to work around it, we've had multiple issues over the years due to specific versions of gcc breaking what we're doing, so we've given up on it. See nothings#280 and nothings#410 for examples.

Some of these libraries seem redundant to existing open source libraries. Are they better somehow?

Generally they're only better in that they're easier to integrate, easier to use, and easier to release (single file; good API; no attribution requirement). They may be less featureful, slower, and/or use more memory. If you're already using an equivalent library, there's probably no good reason to switch.

Can I link directly to the table of stb libraries?

You can use this URL to link directly to that list.

Why do you list "lines of code"? It's a terrible metric.

Just to give you some idea of the internal complexity of the library, to help you manage your expectations, or to let you know what you're getting into. While not all the libraries are written in the same style, they're certainly similar styles, and so comparisons between the libraries are probably still meaningful.

Note though that the lines do include both the implementation, the part that corresponds to a header file, and the documentation.

Why single-file headers?

Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.)

There's also a common problem in Windows where a library was built against a different version of the runtime library, which causes link conflicts and confusion. Shipping the libs as headers means you normally just compile them straight into your project without making libraries, thus sidestepping that problem.

Making them a single file makes it very easy to just drop them into a project that needs them. (Of course you can still put them in a proper shared library tree if you want.)

Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc.

Why "stb"? Is this something to do with Set-Top Boxes?

No, they are just the initials for my name, Sean T. Barrett. This was not chosen out of egomania, but as a moderately sane way of namespacing the filenames and source function names.

Will you add more image types to stb_image.h?

No. As stb_image use has grown, it has become more important for us to focus on security of the codebase. Adding new image formats increases the amount of code we need to secure, so it is no longer worth adding new formats.

Do you have any advice on how to create my own single-file library?

Yes. https://github.com/nothings/stb/blob/master/docs/stb_howto.txt

Why public domain?

I prefer it over GPL, LGPL, BSD, zlib, etc. for many reasons. Some of them are listed here: https://github.com/nothings/stb/blob/master/docs/why_public_domain.md

Why C?

Primarily, because I use C, not C++. But it does also make it easier for other people to use them from other languages.

Why not C99? stdint.h, declare-anywhere, etc.

I still use MSVC 6 (1998) as my IDE because it has better human factors for me than later versions of MSVC.