LodePNG: a PNG codec you drop into your source tree instead of linking against

Two files, no library, no dependencies

The integration story is the product. LodePNG is a PNG encoder and decoder in C and C++ with no dependencies, and you use it by copying `lodepng.cpp` and `lodepng.h` into your own project. The README is explicit that no library artifact is necessary, and it suggests git submodules as the tidier way to track the files.

The README also states that every other file in the repository is a development artifact rather than something you need: source examples, tests, and misc utilities. That distinction matters because the repository root looks like a normal library with eleven files in it, and the actual payload is two of them.

The C89 point is the one that makes it unusual. Beyond C++, the library supports ANSI C with the same functionality, with C++ only adding a convenience API. For C, you rename `lodepng.cpp` to `lodepng.c`. Compiling with `-ansi -pedantic` is how the project keeps that promise honest, since a C89 compiler will reject anything newer.

Documentation lives in a large comment in the second half of `lodepng.h` rather than in a separate site, with examples under `examples/` and an FAQ at the project's home page.

What the Makefile deliberately does not build

The Makefile is short and its header comment explains the design decision better than any documentation could.

It does not make the PNG codec itself as a shared or static library. The stated reason is that LodePNG has only one source file, which can be renamed to `.c`, and is intended to be included as a source file in other projects and their build systems directly. So a `make` here produces development tools, not something you would install.

Four targets come out of it: the unit test, a benchmark, `pngdetail`, and `showpng`.

make -j

`pngdetail` is the interesting one for evaluation, since it is a utility for inspecting what is inside a PNG rather than merely decoding it. `showpng` links against SDL2 and uses `examples/example_sdl.o` to display a file. The benchmark also links SDL2, which suggests it is measuring decode throughput in a context where display matters rather than as a pure library microbenchmark.

The compiler flags are strict by default, with `-W -Wall -Wextra -ansi -pedantic -O3` set for both the C and C++ compilers, and `-Wno-unused-function` added for C. Warnings are not suppressed beyond that single case, so compiling this in a project with its own warning settings may surface noise from code you did not write.

Folding it into your own build

If you have a program that includes `lodepng.h`, the compiler invocation is short. This is the command the README gives for C++:

g++ your_program.cpp lodepng.cpp -Wall -Wextra -pedantic -ansi -O3

The C form is the same with `gcc`, `your_program.c`, and `lodepng.c`. A clang invocation is given as an alternative, and the README notes these commands exist to show the flags the code was designed for rather than to be the way you build, since you would normally use your own project's build system.

That is the whole integration. There is no configure step, no feature detection, no optional dependencies to disable. The cost of that simplicity is equally clear: you inherit the codec whether or not you use every part of it, and when you update you do so by replacing two files.

For a project with its own vendoring discipline, that is a perfectly reasonable arrangement and often the only one available, since many build systems cannot take on a new external dependency at all. For a project that already manages libraries through a package manager, the tradeoff runs the other way, and the same two files are now code you maintain.

What is in the repository beyond the codec

The tree shows the shape of a single maintainer's toolkit. `lodepng.cpp` and `lodepng.h` are the library. `lodepng_util.cpp` and `lodepng_util.h` hold helpers shared by the tools. `lodepng_unittest.cpp` is the test suite, `lodepng_benchmark.cpp` measures performance, `lodepng_fuzzer.cpp` provides fuzzing support, and `pngdetail.cpp` is the inspection utility.

The presence of a fuzzer alongside a unit test is the signal that this code is treated adversarially rather than only feature by feature. PNG decoders are a classic attack surface, since they parse untrusted input by definition, and fuzzing is the standard way to find the memory errors that functional tests miss. The project also links `libtest-mimic`-style tooling in other codebases of this kind, and here the Makefile's separate `unittest` target keeps the test build independent of the library.

Two details tell you how mature the expectations are. There is a `LICENSE` file and GitHub reports the license as Zlib, which is a permissive license chosen specifically to make the code easy to vendor. And there is a `.gitignore`, so the development artifacts these tools produce are kept out of the tree.

The project has no releases at all, which is consistent with the vendoring model. There is no version to depend on through a package manager, so the practical question of which revision to use is answered by whatever commit you copy, which makes the test suite the more important artifact here than a changelog would be.

Where it sits against libpng and other choices

PNG has a well established toolchain, so the honest comparison is with what you would otherwise use. libpng is the reference implementation, maintained by the PNG group and built around zlib. libpng is the choice when you want zlib's compression tuning, full support for the more obscure corners of the PNG specification, and the confidence of a library with a very large user base. It is also a library you link against, with build system integration to arrange.

LodePNG trades all of that for the two-file arrangement and the absence of a zlib dependency, doing its own inflate and deflate work. That is why it fits places libpng is awkward: an embedded target with no zlib, a build toolchain that cannot easily grow a dependency, or a codebase that prefers vendored code. The C89 support extends that reach further back than most modern libraries go.

The other alternatives are smaller or different in kind. stb_image is a single-file codec with a comparable no-dependency approach, and libspng is a newer library that positions itself on throughput. If you are choosing, the practical axes are dependency policy and language standard rather than feature list, since all three produce correct PNG output for ordinary images.

What the README does not give you is a feature matrix against the specification, which makes it hard to know from this repository alone whether a given corner case is handled. That is a real gap for a codec, and it is the reason to run the unit test and the fuzzer against your own inputs rather than trusting the description.

Editorial conclusion

LodePNG earns its place by refusing to be a library. There is no link step, no shared object, no package manager entry, and no ABI to track, so integrating it costs two files and a compiler invocation. The trade is that you take on the code yourself, which is the correct deal for an embedded tool, a build you cannot extend, or a codebase that already vendors code. What the repository does not settle is PNG feature coverage, since the README is a build and integration guide rather than a codec conformance document, and there are no tagged releases to pin a known-good commit to. Drop `lodepng.cpp` and `lodepng.h` into a scratch program, run the included unit test, and check the failing cases against your own PNGs before you rely on it.

Frequently asked questions

Official sources

1. Issues
2. License: Zlib
3. lvandeve/lodepng on GitHub
4. README