# minizip-ng C ZIP Library Features and Build

> minizip-ng is a C library for creating and extracting ZIP archives across Windows, macOS, and Linux. Its streaming architecture supports memory storage, multiple compression methods, disk splitting, and WinZip AES.

**zlib-ng/minizip-ng** — Fork of the popular zip manipulation library found in the zlib distribution.

- Repository: https://github.com/zlib-ng/minizip-ng
- Stars: 1,510 · Forks: 519
- Language: C
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/zlib-ng-minizip-ng

## Why minizip-ng extends original minizip

minizip-ng exists because the original minizip contribution bundled with zlib needed new features and fixes that were not being added there. The README says the code was substantially refactored and rewritten to improve maintainability and readability. This is a functional fork rather than a new archive format, but its API and implementation have evolved beyond the historical version.

The library is aimed at C applications that need direct control over ZIP creation and extraction. It supports Windows, macOS, and Linux, including Win32 and WinRT on Windows. It is also relevant to software that cannot assume users will have a particular command-line archiver installed. Instead of launching an external process, an application can link the library, select a codec, configure streams, and perform archive work in process.

Compatibility with existing minizip users is addressed through a compatibility layer controlled by MZ_COMPAT, which is enabled by default. That can reduce the effort required to migrate an existing integration, but it should not be read as a promise that every original interface, data structure, or binary artifact is unchanged. The README specifically says the old 1.2 branch, which contains WinZip AES, disk splitting, I/O buffering, and additional fixes, is not ABI compatible with original minizip. An upgrade therefore needs source-level review and a rebuild rather than an assumption that an existing library can simply be replaced.

## How minizip-ng separates archive logic from streams

The repository layout shows that ZIP container handling and data movement are implemented separately. Core archive operations are associated with files such as `mz_zip.c` and `mz_zip_rw.c`. Input and output are represented by stream modules prefixed with `mz_strm_`. That arrangement lets archive code work through a stream abstraction instead of being tied directly to one storage mechanism.

Memory access is a concrete example. `mz_strm_mem.c` supports reading and writing ZIP archives from memory, which can matter for mobile applications, services handling uploaded archives, or software that must produce a ZIP result before writing it to disk. `mz_strm_buf.c` adds buffered streaming, while `mz_strm_split.c` handles disk-split archives. Operating-system integration is divided into POSIX and Win32 files, so platform differences have identifiable locations in the source.

The codecs follow the same modular pattern. Separate files exist for Zlib, BZIP2, LZMA and XZ, PPMD, and Zstandard support. Encryption is split across PKWARE, WinZip AES, OpenSSL, Apple, and Windows-specific implementations. This structure makes the central format logic easier to distinguish from dependency selection, but it also means adoption can involve more than the base C files. Build options determine which codec, encryption, encoding, and platform modules are compiled. A small extraction tool may need less than an application intended to create password-protected archives with several compression methods.

## Compression, encryption, and archive edge cases

The listed codec support covers Zlib, BZIP2, LZMA, PPMD, XZ, and Zstandard. ZIP64 support is also present for large-file use cases. These capabilities extend the basic create-and-extract workflow, but they do not make every feature available by default on every host. The CMake options include switches for Zlib, BZIP2, LZMA, PPMD, Zstandard, PKWARE encryption, WinZip AES, OpenSSL, Apple compression, iconv, and ICU.

Password protection has two documented families: Traditional PKWARE and WinZIP AES. They should not be treated as interchangeable labels for one implementation. `mz_strm_pkcrypt.c` and `mz_strm_wzaes.c` are separate components, with MZ_PKCRYPT and MZ_WZAES controlling their compilation. The README also records a `MZ_OPENSSL` option for OpenSSL encryption and platform-specific crypto files. Consumers whose archive policy requires one encryption scheme should make that requirement explicit in build configuration and archive handling code.

Other documented format handling includes UTF-8 filenames, legacy encodings CP437, CP932, CP936, and CP950, NTFS timestamps, preservation of file attributes, and storage or following of symbolic links. The central directory can be omitted or corrupted in some workflows because the library includes central-directory recovery features. These are useful for compatibility and repair scenarios, but they also broaden the behavior that needs testing. Filename encoding, symbolic-link policy, timestamp behavior, and error handling can all vary by operating system and filesystem.

## Building minizip-ng and enabling its tests

The README recommends CMake 3.11 or later. The documented commands configure the source tree in a `build` directory and enable the test executable through `MZ_BUILD_TESTS`:

```bash
cmake -S . -B build -D MZ_BUILD_TESTS=ON
```

This creates the platform-specific project files. The reader should inspect the resulting configuration for unavailable codec or encryption dependencies before proceeding.

The next command compiles the configured project:

```bash
cmake --build build
```

After a successful build, the generated build tree should contain the library, any enabled test executable, and the example command-line tools if they were included by the configuration. The repository includes `minizip.c`, `minigzip.c`, and sources under `test/`. The README does not give exact output paths or a complete invocation for creating and extracting a first archive, so it would be inaccurate to invent one.

The default branch named in the repository metadata is `develop`. The README describes `develop` as the location of the latest development code and `master` as the most recent stable release. Release entries include 4.2.2 dated 2026-06-30, 4.2.1 dated 2026-04-27, and 4.2.0 dated 2026-04-27. A team that requires a stable release should decide which branch and version it intends to pin rather than building an unspecified moving target.

## Configuration choices that change the dependency surface

minizip-ng exposes CMake options that can materially change a build. `MZ_ZLIB_FLAVOR` accepts `auto`, `zlib-ng`, or `zlib`, and its documented default is `auto`. This is significant for projects that need predictable dependency selection, because automatic detection may resolve differently across environments. `MZ_FETCH_LIBS` controls whether missing third-party libraries may be fetched on supported configurations, while `MZ_FORCE_FETCH_LIBS` changes that behavior to always fetch them.

Encoding support is similarly configurable. `MZ_ICONV` is enabled by default, whereas `MZ_ICU` is disabled by default. Both address encoding conversion, but the README does not claim identical platform coverage. A build intended to open archives with legacy character encodings should verify which backend was detected and enabled.

Feature-only modes are available through `MZ_COMPRESS_ONLY` and `MZ_DECOMPRESS_ONLY`, both disabled by default. These options may help reduce surface area for applications with a fixed direction, such as a client that only receives ZIP files. They can also make a build unsuitable if the host later needs the omitted direction. Platform options include `MZ_LIBCOMP`, `MZ_FILE32_API`, `MZ_LIBBSD`, and OS-dependent defaults for `MZ_FETCH_LIBS`, `MZ_OPENSSL`, and Apple compression. Dependency reduction is possible, but the resulting feature contract should be recorded rather than inferred from successful compilation.

## The original minizip tree as a narrower alternative

The original minizip source remains available in zlib's `contrib/minizip` directory. Its main advantage is a closer relationship to the zlib distribution, which may matter to a project already standardized on a particular zlib source tree and compatible contrib code. It is also the alternative to select when the required behavior is limited to the established original interface and the newer fork's codec, encryption, or compatibility choices are unnecessary.

The difference in approach is ownership of modernization. Original minizip follows changes within the zlib distribution. minizip-ng takes a separate fork path, adds codec and archive features, rewrites much of the implementation, and exposes an explicit compatibility layer. That creates room for features such as memory streams, disk splitting, buffered I/O, WinZip AES, recovery of missing central-directory data, and several compression methods. It also creates a migration and dependency decision because applications now need to track the fork's branches, options, and platform builds.

For an application that already depends on the zlib build system and does not need those extensions, the original contrib source can be the simpler dependency. For a new C application that must select a modern codec, stream to memory, split an archive, or use WinZip AES, minizip-ng provides mechanisms not established in the documented feature list for the original contrib source.

## Maintenance, licensing, and adoption boundaries

The repository is not archived, and its last push was on 2026-10-01. Those facts describe repository activity, but they do not remove the need to pin versions and review release changes. The recent release sequence includes multiple 4.2.x releases in April and June 2026, while the default branch is `develop`. Upgrades can therefore involve a choice between following development work or selecting a stable release line.

The repository metadata classifies the licence as custom because GitHub cannot classify the LICENSE file, although the README displays a Zlib licence badge. For compliance purposes, the authoritative project-specific document is `LICENSE`; a badge or metadata classification is not a substitute for reading its terms. This review does not interpret those terms or provide legal advice.

minizip-ng is a poor fit for a project that wants an unmodified original minizip ABI, assumes only deflate, or avoids linking several external codec and encryption libraries. It also requires deliberate handling when archives contain encrypted entries, legacy filenames, symbolic links, or damaged central directories. A native application that needs those capabilities, or that needs ZIP work without an external archiver, has a clearer reason to evaluate it. The first verification should be a target-specific CMake configuration with the required codecs and encryption backends, followed by review of `LICENSE`, the chosen branch, and `MZ_COMPAT`.

## Conclusion

Applications that need native ZIP handling with streaming, memory storage, multiple codecs, disk splitting, ZIP64, or WinZip AES should evaluate minizip-ng first. Projects expecting unchanged original minizip behavior should validate the MZ_COMPAT layer and linked dependencies rather than assuming binary compatibility. Before adoption, check the LICENSE file for the project's custom terms, select develop or master according to the required release policy, and configure the target platform to confirm that every required codec and encryption backend is available.

## FAQ

### What platforms does minizip-ng support?

The README lists Windows, macOS, and Linux. On Windows, it specifically documents Win32 and WinRT support.

### How do I build minizip-ng with its tests?

The README recommends CMake 3.11 or later and configures the project with `cmake -S . -B build -D MZ_BUILD_TESTS=ON`, followed by `cmake --build build`.

### Does minizip-ng remain compatible with original minizip?

The project provides a compatibility layer through the MZ_COMPAT option, which is enabled by default. However, the README says the old 1.2 branch is not ABI compatible with original minizip, so consumers should not assume unchanged binary compatibility.

## Sources

- [Issues](https://github.com/zlib-ng/minizip-ng/issues)
- [README](https://github.com/zlib-ng/minizip-ng/blob/develop/README.md)
- [Releases](https://github.com/zlib-ng/minizip-ng/releases)
- [zlib-ng/minizip-ng on GitHub](https://github.com/zlib-ng/minizip-ng)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zlib-ng-minizip-ng