Oxipng: a multithreaded PNG optimizer you can install from Cargo, a distro package or Docker

The problem Oxipng solves, and who it is actually for

PNG files carry a lot of redundancy that encoders leave behind: filter choices, compression parameters, and metadata chunks that a browser or an image viewer will never read. Oxipng is a lossless optimizer for PNG and APNG that rewrites those decisions. It started in 2015 as a rewrite of OptiPNG, and the README states the original goal plainly: implement multithreading, which would have been difficult inside OptiPNG's C codebase, and pick a safer language while doing it.

The audience is narrow but real. If you ship web assets, a mobile app bundle, or a design system with a checked-in image directory, Oxipng is the kind of tool that runs in a build step or a pre-commit hook and never gets thought about again. The README lists ImageOptim, Squoosh, FileOptimizer, Curtail, pyoxipng, jSquash and Trunk as software using it, which tells you the intended shape: a component inside a larger pipeline, not an application you sit in front of. There is no GUI and no online service mentioned in the repository.

How the optimizer works: filters, recompression, and what the levels mean

The mechanism is a search over PNG encoding decisions. Oxipng refilters the image, recompresses the resulting data, and keeps the smaller result. The -o flag from 0 through 6, or -o max, controls how much of that search happens. Lower is faster, higher compresses better, and the default of -o 2 is described in the README as quite fast with good compression. Higher levels have increasingly diminishing returns.

One line in the README deserves attention because it contradicts how people usually read optimization levels. Oxipng is not a brute-force optimizer, so a higher level is almost always better or equal but not guaranteed to be, and in rare circumstances a lower level may produce a marginally smaller output. The same caveat applies to Zopfli compression via -z. If your build asserts that -o 6 always beats -o 4, that assertion is not something the documentation supports.

Parallelism comes from rayon, and the Cargo.toml shows it as an optional dependency behind the parallel feature, which is on by default. That is the multithreading the project was created for. The compression backend is libdeflater by default, with zopfli as an optional feature for slower, differently-tuned output.

Installing Oxipng and running a first real optimization

The README recommends a distro package on macOS and Linux when the packaged version is not too outdated, and points at the Releases page for Windows downloads. Repology tracks which environments package it. If you prefer a language-level install, Cargo works:

cargo install oxipng

After that, oxipng is on your PATH and oxipng --help prints the option list. The README's own example for web assets combines an optimization level, safe metadata stripping, alpha optimization and a glob of inputs:

oxipng -o 4 --strip safe --alpha *.png

The --strip safe setting removes only metadata that will never affect rendering. --strip all removes everything not critical to the image, and you can also pass a comma-separated list of specific chunks. -s is shorthand for --strip safe. Note that --alpha alters the color values of fully transparent pixels, which the README recommends generally but flags as technically lossy.

For a containerized run, the project publishes an image for linux/amd64 and linux/arm64. The README gives this invocation, which mounts the current directory at /work and optimizes one file:

docker run --rm -v $(pwd):/work ghcr.io/oxipng/oxipng -o 4 /work/file.png

To make the pass automatic, the repository ships a pre-commit hook. The README shows a .pre-commit-config.yaml entry pinned to a release tag:

repos:
  - repo: https://github.com/oxipng/oxipng
    rev: v10.0.0
    hooks:
      - id: oxipng
        args: ["-o", "4", "--strip", "safe", "--alpha"]

Because the tool is lossless apart from --alpha, the check you should run after the first pass is a pixel comparison against the originals, not a visual spot check.

Where Oxipng stops: APNG, --alpha, and the OptiPNG migration trap

The clearest limitation is animated PNG. The README states that Oxipng currently only supports limited optimization of APNGs: it can do alpha optimization, refiltering and recompression of all frames, but all transformations are disabled. For best results it recommends running another tool such as apngopt before Oxipng. If your workload is mostly animated stickers or UI animations, Oxipng is a secondary pass, not the primary tool.

The second limitation is --alpha itself. It is recommended for images with transparency and it improves compression, but it changes the color values of fully transparent pixels. Those pixels are invisible, so the change is invisible too, until something downstream reads the color channel of a transparent pixel. That is a narrow case, but it is the kind of narrow case that shows up in texture pipelines and in tooling that composites against a background color stored in the transparent region.

The third is migration. The README is direct that Oxipng is not a drop-in replacement for OptiPNG despite the shared lineage, and tells anyone migrating to check MANUAL.txt before use. Options that look familiar may not behave identically. Treat a switch from OptiPNG as a project with its own verification step, not a flag rename.

Oxipng against pngquant and against OptiPNG

The comparison people reach for is pngquant, and the difference is categorical rather than a matter of degree. pngquant reduces the color palette, which is a lossy transformation that can shrink files dramatically. Oxipng does not quantize. It searches encoding parameters and keeps the pixel data, with --alpha as the single documented exception. If a PNG has thousands of colors and needs to lose most of them, Oxipng is the wrong tool and pngquant is the right one. If the image must stay pixel-identical, pngquant is the wrong tool.

Against OptiPNG, the difference is architectural. OptiPNG is the C project Oxipng began as a rewrite of in 2015, and the README says the core goal was multithreading, which would have been very difficult in the existing C codebase. Oxipng's parallel feature, backed by rayon, is that goal realized, and the README notes the architecture and capabilities have diverged enough that it is not a drop-in replacement. Note also that "vs browser png" style comparisons are not something the repository addresses: Oxipng is a file optimizer, not a runtime encoder.

Library use, licence, and the cost of keeping up

Oxipng is dual-purpose. The Cargo.toml defines a binary target gated on the binary feature, and the README explains that when you depend on it as a library you should disable default features and name the ones you want, because there is no simple way to disable a single feature in Cargo. The example given is:

oxipng = { version = "10.0", features = ["parallel", "zopfli", "filetime"], default-features = false }

The simplest library path is an Options struct passed with an input filename into the optimize function, both linked from docs.rs. The minimum supported Rust version is 1.85.1 in the README, while Cargo.toml sets rust-version to 1.88.0 and edition 2024; if you are building from source, check both rather than trusting one number.

On maintenance: the last push was on 2026-09-02, and v10.2.1 was released the same day, with v10.2.0 on 2026-08-09 and v10.1.1 on 2026-04-22. The project follows Semantic Versioning, so minor releases are the ones to read for behaviour changes. The upgrade cost is mostly in the Rust toolchain floor, which moves with edition and dependency requirements, and in re-verifying output sizes if you pin an optimization level in CI. The licence is MIT, which is permissive and imposes no copyleft obligation on your own code; that is a statement about the licence text, not legal advice, and the LICENSE file is the authority you should read.

Editorial conclusion

Adopt Oxipng if you already have a PNG pipeline and want a fast lossless pass over it, either as the oxipng binary or as a library dependency with default-features disabled. Do not adopt it expecting a drop-in OptiPNG replacement, a GUI, or a full APNG optimizer; the README points at apngopt for animations and at MANUAL.txt for migration differences. Before rolling it out, verify the behaviour of --alpha on your own transparent assets, since the README calls that transform technically lossy, and confirm the version your distro ships is recent enough for the options you plan to use.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. oxipng/oxipng on GitHub
4. README
5. Releases