NanaZip: the 7-Zip fork that rebuilds the archiver for Windows 11

What NanaZip solves that 7-Zip itself does not

7-Zip's Windows build works, but its interface has not moved with the operating system. NanaZip is a fork of that source tree aimed at what the README calls the modern Windows experience. The compression engine is inherited; the shell is replaced. Concretely, the README lists dark mode for all GUI components, the Mica effect on the main window, MSIX packaging, a Windows 10 and 11 File Explorer context menu, per-monitor DPI awareness, modernized message boxes and folder browsers, a Smart Extraction feature, an Open folder after extraction option, and a policy mechanism for enforcing settings.

The intended audience is narrow and identifiable: people who unpack archives from File Explorer on Windows and are bothered by the visual mismatch. The README also states that NanaZip provides a 7-Zip execution alias to help users migrate, which tells you the project expects existing 7-Zip users to be the main intake. Nobody running a Linux build server needs this. Nobody scripting tar over SSH needs this.

Inherited codecs, reimplemented hashes, and the Windows CNG dependency

The feature list is where the fork's actual engineering shows. NanaZip inherits from 7-Zip 26.03, 7-Zip ZS and 7-Zip NSIS, so the codec set is broader than stock 7-Zip: Brotli, Fast-LZMA2, Lizard, LZ4, LZ5 and Zstandard appear as decoders, encoders or archivers, and several read-only archivers handle formats that are not archives in the usual sense, including UFS/UFS2 file system images, Electron asar bundles, ROMFS, ZealFS, WebAssembly binaries and .NET single-file application bundles.

The hash list is more interesting than it looks. MD2, MD4, MD5, SHA-1 and the SHA-2 family are described as inherited but reimplemented with the Windows CNG API. The rest, from AICH and BLAKE2b through the GOST variants, RIPEMD-160, Snefru, Tiger, TTH and Whirlpool, are implemented with RHash; the XXH family uses xxHash and SM3 uses GmSSL. That is a deliberate pivot toward platform crypto providers for the common algorithms. It also means the hash side is tied to Windows in a way the compression side is not, which matters if you were hoping to lift the codec layer into another project.

Two entries carry explicit caveats in the README itself. The .NET single-file bundle archiver is read-only and does not support extracting compressed files inside the bundle. The littlefs file system image archiver is marked Work In Progress and limited to block information. Treat both as inspection aids, not extraction tools.

Installing NanaZip: Microsoft Store, winget, or the release page

The README points at four distribution channels: the Microsoft Store release channel, the Microsoft Store preview channel, GitHub releases, and a SourceForge mirror. Because the application is packaged with MSIX, the Store route is the one the project designs around. If you use winget, the package identifier follows the Store listing; the README does not print the exact winget identifier, so confirm it with a search rather than guessing.

That command lists matching packages from the configured sources. You should see NanaZip entries; the identifier is what you pass to the install subcommand. If no result appears, your winget source list does not include the Microsoft Store source, and the release page on GitHub is the fallback.

After installation, the visible change is the File Explorer context menu. The README states context menu support for Windows 10 and 11 File Explorer, and it ships a screenshot named ContextMenu.png under Documents/. Right-click an archive and the NanaZip entries appear alongside the shell's own. For a first real use, take a file you already have and run it through Smart Extraction, which the README lists as a feature without further explanation of its heuristics.

The README documents a 7-Zip execution alias, so the command-line surface mirrors 7-Zip's. The README does not print an example invocation, and it does not document the alias's exact binary name, so check the installed path before scripting anything against it. The repository does ship a RestoreNuGetPackages.cmd and a BuildAllTargets.cmd at the top level if you would rather build from source than install.

Mark-of-the-Web propagation and the policy mechanism

Two features deserve separate attention because they change behaviour rather than appearance. The README states that NanaZip propagates Mark-of-the-Web to all files by default. That is a security posture: files extracted from a downloaded archive keep the zone information that makes Windows treat them as untrusted, so SmartScreen and Office protected view still apply after extraction. It is the opposite of the convenience default many users expect, and it is a deliberate choice you should know about before rolling NanaZip out to people who will file support tickets about blocked macros.

The second is the policy mechanism for enforcing settings, documented in Documents/Policies.md. The README does not enumerate the policies in the feature list, so the file itself is the source of truth. This is the feature that makes NanaZip plausible in a managed environment: an administrator can pin behaviour instead of asking users to configure it. If you are evaluating NanaZip for a fleet, read Policies.md before anything else, because it determines whether your requirements are expressible at all.

Where NanaZip is the wrong tool

The platform boundary is absolute. NanaZip is a Windows desktop application built on XAML Islands and WinRT, packaged as MSIX, and the repository gives no indication of a macOS or Linux target. If your workflow crosses operating systems, you will end up with a second archiver anyway, and the consistency argument for choosing NanaZip evaporates.

Portability is the second boundary. MSIX packaging is the deployment model the README leads with, and the README does not describe a portable or no-install build. Anyone who currently carries 7-Zip on a USB stick, or who needs to run an archiver on a locked-down machine without an installer, should assume NanaZip does not fit until they confirm otherwise from the release assets.

The third is the read-only archivers. Several of the more exotic formats, including asar, ROMFS, ZealFS, WASM and the .NET bundle, are extraction-only or partial. The README is explicit that compressed files inside a .NET single-file bundle cannot be extracted. If your job is repacking those formats, NanaZip will open the container and stop there.

Finally, the licence. The repository's License.md is present, but the project metadata carries NOASSERTION rather than a recognised SPDX identifier. That is not a statement that the licence is problematic; it is a statement that automated tooling cannot classify it, and that anyone with a compliance gate needs to read the file rather than trust a scanner.

NanaZip versus 7-Zip, WinRAR and PeaZip

The honest comparison is with 7-Zip, because NanaZip is 7-Zip's source with a new front end. Choosing NanaZip over 7-Zip buys you the Windows integration: dark mode, Mica, per-monitor DPI awareness, MSIX deployment, the modernized dialogs, Smart Extraction, and the policy mechanism. It costs you nothing in codec coverage, since NanaZip inherits 7-Zip 26.03 plus the ZS and NSIS additions. If you never open the GUI and only ever call the command line, the fork offers you very little.

WinRAR is a different proposition entirely. It is proprietary, and its archive format is not the one NanaZip's engine is built around. The comparison people actually search for is about which one to install on a personal Windows machine, and the deciding factor there is usually whether you need RAR creation, which NanaZip does not provide in the same way. PeaZip takes a third approach: it is a cross-platform front end that wraps multiple backends rather than a fork of one engine. That makes PeaZip the better answer when you want one interface on Windows and Linux; it makes NanaZip the better answer when you want 7-Zip's engine with Windows 11 chrome around it.

Maintenance cadence and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-09-21. The release history is dense: 7.0.1843.0 on 2026-09-17, 7.0.1832.0 on 2026-09-06, and a 7.0 preview, 7.0.1800.0, on 2026-08-06. That is a project shipping on a roughly weekly-to-fortnightly rhythm across a release channel and a preview channel, with the Store listing split the same way.

Upgrade cost is low by construction. MSIX packages update through the Store, and the README's preview channel gives you a way to test ahead of the release channel without leaving the packaging system. The maintenance burden is not in the update mechanism; it is in the settings surface. A fork that tracks upstream 7-Zip 26.03 while adding its own codecs and policies will occasionally change defaults, and the Mark-of-the-Web propagation is exactly the kind of default that generates user-visible behaviour changes. The README does not document rollback or downgrade, so plan for the possibility that reverting a bad update means uninstalling and reinstalling from the release page.

On licensing, the repository ships License.md and the metadata reports NOASSERTION. Read the file. This is not legal advice, and the practical point is narrower: do not let an automated dependency scanner's inability to name the licence stand in for actually reading it.

Editorial conclusion

Adopt NanaZip if your archive work happens inside Windows 10 or 11 File Explorer and you want dark mode, Mica and a policy mechanism without giving up 7-Zip's codec coverage. Do not adopt it if you need a portable executable, a macOS or Linux build, or a tool whose licence you can classify at a glance, because the repository ships License.md without an SPDX identifier and the README does not document rollback or downgrade behaviour. Verify two things before deploying: that your target machines meet the Windows 10 or 11 requirement implied by the MSIX packaging, and that the policies you intend to enforce are actually listed in Documents/Policies.md rather than assumed from the feature list.

Frequently asked questions

Official sources

1. Issues
2. M2Team/NanaZip on GitHub
3. Project website
4. README
5. Releases