LZ4 1.11.0, released on November 4, 2026, moves multithreaded compression into the liblz4 frame API, speeds up decompression on x86-64 and aarch64, and fixes several data corruption bugs that could hit perfectly valid usage. The release notes say liblz4 stays binary compatible with earlier versions and recommend upgrading, which makes this a routine but worthwhile update for anyone shipping the library or relying on the lz4 command-line tool.
The key points of LZ4 1.11.0 in 30 seconds
- liblz4 gains experimental multithreaded frame compression, and the output stays identical whatever the thread count.
- The project reports up to 19% faster decompression on x86-64 and aarch64, or 4% on silesia.tar.
- It fixes data corruption bugs and an out-of-bounds write introduced in 1.10.0, with no CVE assigned.
- In our own benchmark on a 2-vCPU virtual machine, LZ4 decompressed far faster than gzip, xz or bzip2, while zstd produced files about 30% smaller.
LZ4 is a lossless LZ77-family algorithm designed by Yann Collet, who also created Zstandard (zstd). It trades compression ratio for raw speed, which is why it turns up in the Linux kernel, zram, OpenZFS, SquashFS and a long list of databases. Version 1.11.0 is the new stable release after 1.10.0 and does not change the .lz4 file format, so archives written by older versions remain readable.
What changes in LZ4 1.11.0
Version 1.10.0 added multithreading to the command-line tool. In 1.11.0 that work lives in the library itself, exposed through the experimental LZ4F_preferences_t.nbWorkers field. According to the changelog, the compressed output does not depend on the number of workers, which matters for reproducible builds and checksummed artifacts. We confirmed that on our test corpus: lz4 -T2 and lz4 --single-thread produced byte-identical files. The CLI now relies on the library for -T#, gains --memory=# to cap the memory budget of threaded compression, and adds --single-thread.
The performance claims, all from the project, are specific: decompression up to 19% faster on aarch64 and x86-64 (4% on silesia.tar), small-block compression at fast levels up to 80% faster with reused states and 35% faster with dictionaries, levels 11 and 12 between 8% and 27% faster, and level 2 compressing about 0.8% better. x86 builds now avoid Intel’s JCC erratum penalty, worth up to 12% in compression and 31% in decompression on Skylake-family CPUs, according to the changelog.
The fixes deserve attention. LZ4 1.11.0 corrects data corruption in ring buffer decoding (present since 1.9.0) and in rare streaming or destSize compression cases, a truncation bug when the single-threaded CLI decoded concatenated frames with block checksums, and an out-of-bounds write in multithreaded decompression after 2^31 frames, introduced in 1.10.0. Invalid arguments such as negative sizes or NULL pointers no longer crash the library. Neither the release notes nor the changelog list a CVE (Common Vulnerabilities and Exposures) identifier for any of these issues.
Developers should check a few API changes. LZ4_decompress_safe() now returns distinct error codes (-1 for malformed input, -2 when the destination is too small, -3 for a missing dictionary). New static functions LZ4F_resumeFrame(), LZ4F_seek() and LZ4F_tell() add random access within frames. Functions deprecated since 1.7 and 1.8 leave the headers, although liblz4 still exports them, LZ4_resetStream() and LZ4_resetStreamHC() are deprecated, and LZ4F_compressOptions_t must be zero-initialized. On the build side, CMake exports an lz4::lz4 target, and the shared library is multithreaded by default while the static one is single-threaded. The CLI can also decode Firefox mozlz4 files and refuses to overwrite its own input.
Distribution packages will lag for a while. Ubuntu 24.04 still ships LZ4 1.9.4, which has no -T option, so we built 1.11.0 from the tag. These commands were run on that build:
sudo apt install lz4 # distro package (1.9.4 on Ubuntu 24.04)
git clone --branch v1.11.0 https://github.com/lz4/lz4.git
cd lz4 && make -j"$(nproc)" && sudo make install
lz4 --version
lz4 -9 data.tar # high compression (HC), writes data.tar.lz4
lz4 -T2 --memory=512M -f data.tar data.tar.lz4 # two threads, capped memory
lz4 -t data.tar.lz4 # integrity test
lz4 -d data.tar.lz4 restored.tar # decompress
lz4 --list data.tar.lz4 # frame information
tar -I lz4 -cf backup.tar.lz4 /path # use lz4 with tar
lz4 -b1 -e3 data.tar # in-memory benchmark, levels 1 to 3Code language: PHP (php)On Fedora, RHEL and their rebuilds the package is also called lz4 (sudo dnf install lz4); which version you get depends on the release.
LZ4 vs zstd, gzip, xz, 7z, RAR, bzip2, Brotli and Snappy: our test
A quick distinction first. LZ4, zstd, Deflate and LZMA are algorithms. gzip, xz, bzip2, zstd and lz4 compress a single stream, which is why Linux users pair them with tar. zip, 7z and RAR are archive formats that store many files and directory metadata and use an algorithm underneath: zip usually relies on Deflate and 7z on LZMA2. RAR is proprietary; unrar is free to use, but the rar compressor is commercial software.
Our numbers come from a reproducible 102,963,200-byte tar of the kernel, mm, fs and net directories of the Linux 6.8 source tree (Ubuntu’s linux-source-6.8.0 package). The machine was a KVM guest with 2 vCPUs of an Intel Xeon at 2.10 GHz running Ubuntu 24.04. Each figure is the best of three wall-clock runs of the command-line tool, reading from the page cache and writing to disk or /dev/null, single-threaded unless stated. Snappy has no standard CLI, so it was timed in memory through its C API. Treat the results as indicative: this is a virtualized environment and source code compresses unusually well.
| Tool and level | Ratio | Compression (MB/s) | Decompression (MB/s) | License | Typical use |
|---|---|---|---|---|---|
| LZ4 1.11.0 -1 | 2.741 | 329 | 830 | BSD-2 (library), GPL-2.0+ (CLI) | zram, ZFS, logs, real-time data |
| LZ4 1.11.0 -1 -T2 (2 threads) | 2.741 | 522 | 967 | BSD-2 / GPL-2.0+ | Large dumps in parallel |
| LZ4 1.11.0 -9 (HC) | 3.788 | 32.5 | 949 | BSD-2 / GPL-2.0+ | Write once, read often |
| LZ4 1.11.0 -12 | 3.827 | 17.7 | 1,036 | BSD-2 / GPL-2.0+ | Boot images, firmware |
| Snappy 1.1.10 (C API, in memory) | 2.645 | 444 | 753 | BSD-3 | Databases, RPC |
| zstd 1.5.5 -1 | 3.929 | 262 | 958 | BSD or GPLv2 | Btrfs, streaming, fast backups |
| zstd 1.5.5 -3 | 4.403 | 176 | 780 | BSD or GPLv2 | General purpose |
| zstd 1.5.5 -19 | 6.216 | 1.3 | 543 | BSD or GPLv2 | Package distribution |
| gzip 1.12 -6 (Deflate) | 4.417 | 30.2 | 185 | GPLv3 | Universal compatibility, web |
| pigz 2.8 -6 (2 threads, Deflate) | 4.416 | 96.6 | 467 | zlib | Parallel gzip |
| zip 3.0 -6 (archive, Deflate) | 4.417 | 29.5 | 160 | Info-ZIP (BSD-style) | Exchange with Windows and macOS |
| bzip2 1.0.8 -9 | 5.787 | 11.5 | 28.7 | BSD-style | Legacy archives |
| xz 5.4.5 -6 (LZMA2) | 6.324 | 1.4 | 108 | Public domain (0BSD since 5.6) | Source tarballs, packages |
| 7-Zip 23.01 -mx=5 (7z archive, LZMA2) | 6.276 | 1.4 | 104 | LGPL with BSD parts | Maximum-ratio archiving |
| RAR 7.00 -m3 (archive) | 5.771 | 3.4 | 249 | Proprietary (free unrar) | Archives with recovery records |
| Brotli 1.1.0 -q 5 | 5.188 | 37.4 | 445 | MIT | HTTP compression |
CLI timing includes process start-up, file I/O and checksums, which hides much of LZ4’s advantage. Measured in memory with the tools’ own benchmark modes, LZ4 1.11.0 level 1 reached 453 MB/s compression and 2,478 MB/s decompression, and level 9 data decompressed at 2,698 MB/s. zstd 1.5.5 -1 scored 322 MB/s and 1,175 MB/s in the same setup.
Published benchmarks show the same ordering at different absolute values. The LZ4 1.11.0 README (lzbench 2.4.1, GCC 13.3, Core i7-9700K, Silesia corpus) lists LZ4 at a 2.112 ratio with 770 MB/s compression and 4,950 MB/s decompression, against 2.896, 510 MB/s and 1,570 MB/s for zstd 1.5.7 -1. The zstd README, on the same CPU model but built with GCC 14.2, gives LZ4 1.10.0 675 MB/s and 3,850 MB/s. lzbench 2.4 on an AMD EPYC 9555P measures LZ4 1.10.0 at 550 MB/s and 3,832 MB/s, and xz 5.8.4 -9 at 2.75 MB/s compression. CPU, compiler, version and corpus explain the gaps.
Which compressor fits which job
LZ4 is the pick when decompression latency sits on a hot path. zram, the compressed RAM block device, offers lz4 alongside zstd and lzo-rle. OpenZFS uses LZ4 as its default algorithm when compression=on is set. SquashFS and initramfs images can use it to boot faster at the cost of some size, and the kernel image itself can be built with CONFIG_KERNEL_LZ4. Btrfs is the exception: it supports zlib, LZO and zstd, but not LZ4, as covered in our piece on realtime zstd compression in Btrfs. Among databases, PostgreSQL accepts lz4 for TOAST compression and ClickHouse uses LZ4 by default.
zstd is the all-rounder. At level 1 it produced a file 30% smaller than LZ4 -1 in our test with similar CLI decompression speed, and its higher levels approach xz. That balance explains why Arch Linux and Fedora use it for packages and why many backup tools default to it. xz and 7z deliver the best ratios but compress at little more than 1 MB/s per thread here, so they suit source tarballs and software that is compressed once and downloaded many times. gzip and zip remain the compatibility choice, and pigz is the easy way to put more cores behind gzip. bzip2 is outclassed on almost every axis, Brotli is still a common choice for web assets, and RAR only makes sense when its format is required. For a look at multithreaded archiving, see our comparison of 7-Zip 25.00 beyond 64 threads.
Frequently asked questions
Can LZ4 1.11.0 read files created by older versions?
Yes. The file format is unchanged, and the project states that liblz4 remains binary compatible with previous versions.
Does LZ4 1.11.0 fix any CVE?
No CVE is listed. The release does fix data corruption bugs in valid usage and an out-of-bounds write in multithreaded decompression introduced in 1.10.0.
Is LZ4 faster than zstd?
At default levels LZ4 compresses faster, and in memory it decompressed about twice as fast as zstd in our test; through the CLI, I/O narrows that gap. zstd produces noticeably smaller files.
How do I compress with multiple threads in LZ4?
Use -T followed by the thread count, for example lz4 -T4 file, and cap memory with –memory in 1.11.0. The output is the same as a single-threaded run.
Sources: