7-Zip ZS: Zstandard, Brotli and LZ4 inside the 7z container
7-Zip with support for Brotli, Fast-LZMA2, Lizard, LZ4, LZ5 and Zstandard
At a glance
- What is it?
- mcmilk/7-Zip-zstd is a fork of 7-Zip that adds six extra codecs to the archive format and to the command line. It suits people who already trust 7z and want zstd or LZ4 without a second toolchain; it is a poor fit if you need the upstream binary, a documented plugin ABI, or a package manager to do the work.
- Who is it for?
- Adopt it if you already script 7z and want zstd, Brotli or LZ4 inside the same container, or if you want .zst and .lz4 files handled by the archiver you already have. Do not adopt it if you need the upstream 7-Zip binary, a published plugin interface, or a distribution package that stays current on its own.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What 7-Zip ZS adds that upstream 7-Zip does not have
Upstream 7-Zip ships LZMA, LZMA2, BZip2, Deflate, Deflate64, PPMd and the usual BCJ filters. That set is old and slow to compress at high ratios, and it has no modern general-purpose codec. 7-Zip ZS keeps all of it and adds six: Zstandard v1.5.7 (levels 1 to 22), Brotli v1.2.0 (levels 0 to 11), LZ4 v1.10.0 (levels 1 to 12), LZ5 v1.5 (levels 1 to 15), Lizard v2.1 (levels 10 to 49) and Fast LZMA2 v1.0.1 (levels 1 to 9).
The README describes Fast LZMA2 as "20% to 100% faster than normal LZMA2 at levels 5 and above, but with a slightly lower compression ratio", and notes it uses much less additional memory per thread than standard LZMA2. That is the codec to look at first if you compress large trees on a machine where LZMA2 memory per thread is the binding constraint, not the clock.
The audience is narrow and specific. It is for people who already drive 7z from scripts or from the Windows shell and want a codec choice that upstream does not offer, without adding a separate zstd or brotli binary and a second set of file extensions to their pipeline. The README also lists plain file handling for Brotli (.br), Lizard (.liz), LZ4 (.lz4), LZ5 (.lz5) and Zstandard (.zst), so the fork doubles as a decompressor for those formats.
Two installation paths: full setup or codec plugin
The README states there are two ways to install it. The first is a complete setup that includes GUI additions and a modified Explorer context menu. The second is only the codec plugin, which goes into an existing 7-Zip installation and brings no GUI changes and no additional hashers.
That second path is the important one, because it means you do not have to replace your 7-Zip. The README gives this check command, run from the install directory, which lists the libraries, formats, codecs and hashers the binary can see:
7z.exe iOn a working full installation the output names the DLL path, for example c:\Program Files\7-Zip-Zstandard\7z.dll, and then a Codecs block. The entries to look for are BROTLI, LZ4, LIZARD, LZ5, ZSTD and FLZMA2, alongside the stock LZMA, LZMA2, PPMD, BZip2 and Deflate. If those six are absent, the plugin did not load and no amount of archive testing will help.
The README is explicit about which binary does what, and this is the part most likely to trip people up. 7z loads its modules and codecs through 7z.so, so it is the plugin-capable one. 7zz is the official standalone binary used in Linux and macOS packages and takes no external plugins. 7za supports fewer archive formats than 7z (the README calls it minimal, plus LZ4 and hashes). 7zr is the light standalone build focused on the 7z format and carries FLZMA2 and Zstd. If you install only the plugin and then call 7zz out of habit, you will get upstream behaviour with none of the added codecs.
Checking a build before you trust it with real archives
The README's own verification example is the listing command, and it is worth reading the output rather than glancing at it. The sample in the README shows a Formats section that includes a zstd line with the extensions zst, zstd, tzst (.tar) and tzstd (.tar) and a signature starting 0 x F D 2 F B 5 2 5, which is the Zstandard magic number. It also shows the 7z format line and the Cab line, so you can see at a glance which formats the binary recognises.
Below that, the Codecs section is where the fork's additions appear as separate rows with their own identifiers: BROTLI, LZ4, LIZARD, LZ5, ZSTD and FLZMA2, each alongside the stock Copy, Deflate, Deflate64, BZip2, LZMA, LZMA2 and PPMD entries and the BCJ, BCJ2, PPC, IA64, ARM, ARMT, SPARC, Swap2, Swap4 and Delta filters. The Hashers section in the same output lists BLAKE2sp, BLAKE3, CRC32, CRC64, MD2, MD4, MD5, SHA1, SHA256, SHA384, SHA512, SHA3-256, SHA3-384, SHA3-512, XXH32 and XXH64.
There is a practical reason to read the whole block rather than search for one name. The README ties the hashers to the full setup: the codec-plugin path brings "no GUI changes and no additional Hashers". So if a script depends on BLAKE3 or XXH64 for integrity checks, installing the plugin alone will not give you those, even though the archive codecs are present. The listing tells you which of the two installations you actually have.
The codec plugin has no documented interface, and the fork has no upstream path
The README does not describe a plugin ABI. It tells you that 7z loads modules through 7z.so and that 7zz does not accept external plugins, but it does not document the interface a codec must implement, so building your own codec against this tree means reading the C sources under C/ and CPP/ rather than following a specification. That is a real cost if you were hoping to add an in-house codec.
The second limitation is structural. This is a fork of 7-Zip, and the README presents it as such. Upstream 7-Zip has no obligation to keep any internal detail this fork depends on, and there is no stated mechanism for merging upstream changes. Practically, that means codec support here is a feature you get from this project and not from 7-Zip, and it stays that way until upstream decides otherwise.
The third is the one users notice first: false positives from antivirus tools and VirusTotal. The README addresses it directly, saying "It's not maleware" and pointing out that release downloads are generated by GitHub Actions on GitHub's own machines. The README asks people not to open new issues about it and instead to contact the antivirus vendor to have the false positive removed, and it points to issue #451 as a running list. The README's verification route is to open the GitHub Actions run for the tag, download the artifact named 7-Zip ZS Release binaries.zip, and compare SHA256 hashes against the release files. That is a workable check, but it is manual, and it does not stop a corporate endpoint agent from quarantining the binary before you get that far.
Where it is the wrong tool: LZMA2, and the platforms the README does not cover
If your priority is the smallest possible archive and you are willing to wait, plain LZMA2 is still the right answer, and this fork does not change that. The README describes Fast LZMA2 as faster than normal LZMA2 at levels 5 and above "with a slightly lower compression ratio", so even the fork's own LZMA2 variant trades ratio for speed. Zstandard at level 22 will beat LZMA2 on time in most cases, not on size.
If you need the upstream 7-Zip binary specifically, for a signed installer, a distribution package, or an environment where only the official build is allowed, this fork is the wrong tool regardless of how well the extra codecs work. The same applies if you need 7zz: the README states it is the official standalone binary with no external plugin support, so the added codecs cannot reach it.
The README is written around Windows and around the Linux and macOS packaging that 7zz comes from. It does not walk through a Linux build from source, does not list distribution packages, and does not state which architectures the release artifacts cover. The repository does contain Asm/, C/, CPP/ and tests/ at the top level, so a source build is clearly the intended path for some users, but the README does not give the commands for it. If you are on Linux and not using a prebuilt artifact, budget time to work that out from the tree rather than from the documentation.
Alternatives, and the actual difference in approach
The nearest alternative is upstream 7-Zip itself. Same container format, same command line, same LZMA2 and PPMd, no extra codecs. The difference is not quality, it is surface area: upstream has a smaller codebase and a single vendor, and it does not carry six third-party compression libraries. If you never compress with zstd and never open a .zst file, upstream is the lower-risk choice, and any archive this fork writes with LZMA2 will extract there.
The other alternative is to keep 7-Zip for archives and use the standalone zstd and brotli tools for streams, which is how most pipelines already work. That approach keeps each tool upstream and independently updated, at the cost of two vocabularies: 7z for .7z and tar, zstd for .zst, brotli for .br. The fork's value is that it collapses those into one binary and one set of switches, and that it can put zstd or LZ4 inside a 7z container with encryption and the rest of the 7z feature set around it. If your workflow already treats archives and streams as separate steps, the fork buys you little.
Maintenance, upgrades and what the licence file actually says
The repository is not archived, and the last push was on 2026-09-20. Releases are frequent and versioned against both upstream 7-Zip and the zstd library: v26.02-v1.5.7-R2 on 2026-07-09, v26.02-v1.5.7-R1 on 2026-06-27, and v26.01-v1.5.7-R1 on 2026-06-13. The naming makes the upgrade cost visible before you download: the first component tracks the upstream 7-Zip base and the second tracks the bundled zstd version, so a move from v26.01 to v26.02 is an upstream rebase, not a codec bump.
That has a practical consequence for anyone pinning versions in a build script. Two release numbers can differ in the 7-Zip base while sharing the same zstd version, which means the archive format behaviour may change even though the codec did not. Read the release tag, not just the codec version, when deciding whether an upgrade is routine.
On licensing, the repository carries a COPYING file and GitHub reports the licence as NOASSERTION, meaning no SPDX identifier was detected. The README does not state a licence, and nothing here says which terms apply to the fork's own additions as distinct from upstream 7-Zip and the bundled compression libraries. Read COPYING in the tree and check the terms of each bundled library before redistributing a build; this is a fact about the repository, not legal advice.
Editorial conclusion
Adopt it if you already script 7z and want zstd, Brotli or LZ4 inside the same container, or if you want .zst and .lz4 files handled by the archiver you already have. Do not adopt it if you need the upstream 7-Zip binary, a published plugin interface, or a distribution package that stays current on its own. Before trusting it with anything irreplaceable, run 7z i and confirm that ZSTD, BROTLI, LZ4, LZ5, LIZARD and FLZMA2 appear in the Codecs list, then create one archive with each codec you plan to use and extract it with the same binary. The repository carries COPYING, not an SPDX identifier, so read that file yourself before redistributing a build.
Frequently asked questions
Does 7-Zip support zstd?
Upstream 7-Zip does not. This fork adds Zstandard v1.5.7 at levels 1 to 22, and the README shows ZSTD appearing in the Codecs list printed by 7z i.
Which is faster, LZ4 or zstd?
The README gives LZ4 compression speed at 400 MB/s per core with an extremely fast decoder in the multiple GB/s range, and describes Zstandard as offering a wide compression to speed trade-off backed by a very fast decoder. It does not put the two on a single scale, so the honest answer is that LZ4 is the speed-first codec and zstd is the one with the wider tuning range.
Which is better, LZMA2 or zstd?
The README does not rank them. It does say the fork's Fast LZMA2 variant is 20% to 100% faster than normal LZMA2 at levels 5 and above with a slightly lower compression ratio, which tells you the trade runs in the same direction: LZMA2 for size, zstd for time.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/mcmilk-7-zip-zstd)