Leanify shrinks archives and binaries by stripping what the format does not require

It removes data the format does not need, then recompresses

Leanify is a lightweight lossless file minifier and optimizer written in C++. The README describes the mechanism in one sentence: it removes unnecessary data such as debug information, comments and metadata, and recompresses the file to reduce its size, without reducing image quality at all.

The word lossless is doing real work in that sentence. Nothing is re-encoded at lower quality, and no pixels change. What changes is the container. A PNG loses its ancillary chunks, keeping only tRNS for transparency, the fdAT, fcTL and acTL chunks that APNG needs, and npTc for Android 9Patch images, and is then run through ZopfliPNG. A JPEG loses its application markers, Exif, ICC profile, XMP and comments, and is optimized with mozjpeg, unless you pass --keep-exif.

XML based formats are handled by deleting comments, unnecessary spaces, tabs and line breaks, and SVG additionally loses metadata, shrinks spaces inside attributes, drops empty attributes and removes empty text and container elements.

The result is a file that any conforming reader will open. That is the appeal: nothing about the content changes, only the bytes that described it. The README also carries a disclaimer that the author is not responsible for any consequence of using Leanify, and it asks in capitals to back up the file before using it. Given what the tool does to executable headers, that request is not ceremonial.

Recursion through nested containers and detection by content

Two design choices make Leanify different from a single format tool.

The first is recursive minifying. The README gives the example of a PNG inside an APK inside a ZIP, which is a realistic Android build output rather than a contrived case. Any container format Leanify supports has its inner files minified too, and the recursion depth is bounded by an option.

The second is that Leanify can identify a file format by its data rather than by its name. The same property is listed under the features as the ability to identify file format by its data instead of name. That matters in practice because archive contents often carry wrong or absent extensions, and because a tool that trusts extensions will quietly skip or mis-handle files.

Everything happens in memory, with no temporary files, and the whole program is a single file under 1MB with no external dependency. The bundled libraries are compiled in, which is what keeps that true: the Makefile object lists cover LZMA, mozjpeg, pugixml, zopfli and zopflipng.

Cross platform support covers Windows, Linux and Mac, and a directory can be traversed recursively, so pointing the tool at a build output directory is the intended way to use it on a project.

The archive formats are rewritten field by field

ZIP is the case that shows the depth of the approach. Leanify minifies every file inside and recompresses the deflate stream using Zopfli, which is a slower and denser deflate encoder. It falls back to the STORE method when DEFLATE would actually make the file larger. Then it removes the extra field in the local file header, removes the data descriptor structure and writes that information into the local file header instead, removes the extra field and the file comment in the central directory file header, and removes the comment in the end of central directory record.

Each of those removals is a spec-permitted field that some writers include and some readers ignore. Removing them is safe for readers and slightly hostile to tools that expect them, which is the trade the tool is making.

For gzip the same idea applies to the optional sections FEXTRA, FNAME, FCOMMENT and FHCRC, after which the contained file is minified and the deflate stream recompressed.

PE executables are where the risk concentrates. The tool minifies embedded resources, removes the Relocation Table from the executable, removes the undocumented Rich Header, and overlaps the PE Header with the DOS Header. Those last three are structural edits to a file format where third party tooling has come to depend on undocumented parts, and the Rich Header in particular is used by some software to identify the build tools used to produce a binary. A file that opens fine can still be rejected by a security product or a driver loader.

Signed formats need a decision before you run

Two of the supported formats carry an explicit warning in the README, and both are worth reading before you point the tool at a release artefact.

The first is APK. Leanify notes that modifying files inside an APK breaks the digital signature, and that to install it you have to sign it again. The second is XPInstall, the .xpi format, with the same note for the same reason.

There is a middle path for APK, and the README gives it: if you do not want to modify any files inside the APK, use the -d 1 option, which sets the maximum recursive depth to 1 and disables recursive minifying. The container is still processed, but its contents are left alone, which preserves the signature. The same flag works for any archive where the inner files must not change.

That makes the -d option the single most important line in the usage output for anyone shipping signed archives. Without it you will silently break a signature and discover the problem at install time rather than at build time.

The Office document formats have their own gap. The 2007 to 2013 formats, .docx, .xlsx and .pptx, are supported, but the 1997 to 2003 formats .doc, .xls and .ppt are explicitly not supported.

Command line flags that control depth, effort and output

The usage output is short and every option matters.

Usage: leanify [options] paths
  -i, --iteration <iteration>   More iterations produce better result, but
                                  use more time, default is 15.
  -d, --max_depth <max depth>   Maximum recursive depth, unlimited by default.
                                  Set to 1 will disable recursive minifying.
  -f, --fastmode                Fast mode, no recompression.
  -q, --quiet                   No output to stdout.
  -v, --verbose                 Verbose output.
  -p, --parallel                Distribute all tasks to all CPUs.
  --keep-exif                   Do not remove Exif.

The iteration default of 15 is the knob to understand first, since it is where the time goes. More iterations produce a better result at the cost of more time, and that cost is what makes the Zopfli based recompression slow in the first place.

Fast mode skips recompression entirely, so it keeps the structural removals and skips the expensive part. That makes it the sensible setting for a quick check or a large tree, and the wrong setting if size is the point.

Parallel mode distributes the tasks across all CPUs, which matters because the work is per file and independent. Verbose and quiet control stdout, which is worth setting when you run the tool in a build script and do not want its output mixed into your build log.

A typical safe first run on a signed archive is a single file with the depth limited, quiet output and fast mode, so you can see the effect before committing to a slower, deeper run.

Building it yourself with a bundled copy of every codec

There are no releases for every platform in the usual sense, so building is a normal path. On Linux and Mac the requirement is gcc 5 or newer, or clang 3.6 or newer, and the build is a single make invocation.

make

On Windows there are two routes, Visual Studio 2015 or newer through Leanify.vcxproj, or gcc 5 or newer using build_gcc.bat or mingw32-make.

The Makefile is where the design shows. Everything is compiled with -O3, -flto and -std=c++17, with -fno-rtti, and the object lists include the full mozjpeg encoder and decoder, the LZMA codec used for Flash recompression, pugixml for XML parsing, zopfli for deflate and zopflipng with lodepng for PNG work. PREFIX defaults to /usr/local, and the platform branches add -lshlwapi on Windows and -liconv on Darwin, with -s used to strip the binary everywhere except macOS where it is described as obsolete.

That dependency set explains the under 1MB single file claim and the absence of external requirements at runtime. It also means you are compiling third party C and C++ code from a repository that has not cut a release since 2015.

The Windows nightly builds are produced by AppVeyor and the Linux and macOS side uses GitHub Actions, both with badges in the README, and the project also ships a SECURITY.md file, which is a small signal that the maintainer takes reports seriously.

What a decade between releases means for a file rewriting tool

The release history is the weak point. The newest tag is v0.4.3 dated 2015-11-26, before v0.4.2 from 2014 and v0.4.1 from 2014. The repository is not archived and the last push was on 2026-06-05, so the source is being touched, but there is no tagged artefact newer than 2015 and the README points to a Windows nightly build for current binaries rather than to a release.

That gap matters more here than it would for an ordinary command line tool. Leanify rewrites binary formats at the byte level, and format handling changes over time. New PNG ancillary chunks, newer mozjpeg behaviour, newer ZIP features or Android packaging conventions are exactly the kind of thing a five year old tag will not know about. A C++ tool also inherits compiler and platform issues, since the codebase targets gcc 5 and Visual Studio 2015 as floors.

The CHANGELOG.md file in the tree is where to look for what has changed since the last tag, and building from master rather than downloading v0.4.3 is the safer choice if you accept building it.

Licensing is MIT with a LICENSE file at the root, which is the most permissive and least surprising outcome, and the copyright holders for the bundled codecs are recorded in their own directories.

Where an archiver with better compression is the better tool

The realistic alternative for a lot of use cases is not another minifier but a different way of building the artefact. If your ZIP is large because the files inside it are large, no amount of container rewriting will fix that, and the honest answer is to compress the payloads properly before they enter the archive, or to serve the files with compression at the HTTP layer instead of shipping a compressed archive at all.

Where Leanify differs is in the structural work. A standard archiver recompresses entries and leaves headers as the writer chose to write them. Leanify rewrites the container, which means it can remove the extra fields, the data descriptors and the central directory comments, and can recurse into nested archives and images. That is a genuinely different operation, and for a distribution format where every byte ships to every user it can be worth it.

For images the comparison is different again. Lossy optimisers reduce quality and can shrink much more. Leanify explicitly will not reduce image quality at all, which makes it the safe choice for art, screenshots and icons where a visible artefact is unacceptable, and the wrong choice if the only goal is the smallest possible file.

For PE files the honest comparison is with no tool at all. Removing a relocation table or a Rich header is the kind of change that can break a binary in ways that only show up on someone else's machine, which is why the backup warning in the README matters and why the PE support deserves its own test pass before it touches anything you ship.

Editorial conclusion

Leanify suits a developer who ships desktop builds or static assets and wants a smaller APK, ZIP, EPUB or PNG without giving up a single pixel of image quality, since the tool only removes data the formats do not require and it can work through nested containers. It is the wrong tool for signed artefacts you cannot re-sign, for PE executables whose relocation table or Rich header other software depends on, and for anyone who wants a maintained release line, because the newest tagged version is v0.4.3 from 2015-11-26. Before running it, copy the file, because the README asks you to back up anything you pass to it, and read the section on your specific format, since the behaviour differs sharply between a PNG and an .exe.

Frequently asked questions

Official sources

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