Factodus

LZX vs XPRESS for games: which Windows compression algorithm to pick

By Factodus · updated

When you compress a game folder with compact /exe or a tool built on the same Windows feature, you choose one of four algorithms: XPRESS4K, XPRESS8K, XPRESS16K or LZX. Microsoft’s own one-line summary is that XPRESS4K is the fastest and LZX the most compact. This guide explains what sits behind that line, shows what we measured and what we did not, and ends with a way to choose.

Short version. LZX saves the most space and costs the most CPU while compressing. XPRESS saves less and is lighter. For games you install once and play for months, LZX is usually worth trying first. If a particular game feels worse, decompress it or switch it to XPRESS.

What the four algorithms are

All four belong to the Windows Overlay Filter (WOF), the file system filter that has stored files compressed since Windows 10. A compressed file keeps its name, size and contents; the compressed data lives in a hidden stream of the file, and WOF decompresses it whenever a program reads the file. Programs, games included, see the original bytes.

WOF does not compress a file as one block. It cuts it into chunks and compresses each chunk on its own, which is what lets Windows read the middle of a file without decompressing everything before it. Microsoft documents the four options like this:

Algorithm Chunk size What Microsoft says it is for
XPRESS4K 4 KB Computationally lightweight, rapid access to data. The default.
XPRESS8K 8 KB The same XPRESS algorithm with larger chunks.
XPRESS16K 16 KB The same XPRESS algorithm with even larger chunks.
LZX 32 KB Highly compact, a small footprint for data that is accessed infrequently.

Two things change between them:

  • The algorithm. XPRESS is a fast, simple compressor. LZX searches much harder for repeated data, which finds more savings and takes far more CPU time to compress.
  • The chunk size. A bigger chunk gives the compressor more data to find repetitions in, so the ratio improves. The flip side is that reading even a small piece of a file means decompressing the whole chunk it lives in, so a bigger chunk means more work for each small read.

These files are meant to be read, not rewritten. When a program opens a compressed file for writing, Windows turns it back into a normal uncompressed file. That is why game updates undo part of the savings, and why WOF suits game installs: most of a game’s files are only ever read.

CPU versus ratio

There are two separate costs, and it helps to keep them apart.

Compressing is a one-off cost. You pay it once per file, and again only for files that an update rewrote. LZX is much slower here. To put a number on it, we ran compact.exe on synthetic test files (see below): the same 48 MB took about 4 seconds with LZX and well under a second with any XPRESS variant, on the same PC. For a large game that difference is minutes, but you wait for it once.

Decompressing happens every time the game reads data, for as long as the game stays compressed. This is the cost that could, in principle, affect loading. XPRESS is designed to be cheap to decompress; LZX costs more CPU per byte read. Against that, a compressed game reads fewer bytes from the drive, which helps on slow drives.

What we can say from our own use: in our tests with LZX, load times showed no noticeable difference. We have not measured load times or frame times side by side for XPRESS and LZX, so we will not give you numbers for that, and our experience on our hardware is not a guarantee for yours.

What we measured on real games

These are our own results with LZX, on four installed Steam games. After every compress, decompress and cancel we ran Steam’s Verify integrity of game files; Steam never had to redownload a file.

Game Size before (as shown, rounded) Freed with LZX Share of size
Dota Underlords ≈3.0 GB 805 MB ≈26%
Unturned ≈2.1 GB 752 MB ≈35%
Stumble Guys ≈2.3 GB 599 MB ≈25%
Brawlhalla ≈1.4 GB 22 MB ≈1.5%

We did not measure XPRESS on these games, so there are no XPRESS numbers in this table. The only XPRESS figure we have for them is an estimate: before compressing, ShelfSpace forecast about 1.9 GB (range 1.3–2.3 GB) for the four games with XPRESS8K and about 2.6 GB (range 1.4–3.1 GB) with LZX. The real LZX result was 2.1 GB. Treat the XPRESS figure as a forecast, not a measurement.

A synthetic comparison of all four

To show how the four algorithms relate to each other, we generated three kinds of test data in a scratch folder and compressed a copy with each algorithm using compact.exe on Windows 10. This is synthetic data, not a game. Real games mix many kinds of files, and your ratios will be different; the point is the ordering, not the numbers.

  • Text-like: 16 MB of JSON records, standing in for configs, scripts and localisation files.
  • Structured binary: 16 MB of smooth float arrays, loosely like mesh or animation data.
  • Random: 16 MB of random bytes, standing in for data that is already compressed.

Stored size on disk, in MB (lower is better):

Algorithm Text-like Structured binary Random All 48 MB Time to compress
XPRESS4K 5.7 9.9 16.0 31.6 0.4 s
XPRESS8K 5.0 9.4 16.0 30.4 0.4 s
XPRESS16K 4.6 9.1 16.0 29.7 0.3 s
LZX 3.5 6.8 16.0 26.4 4.0 s

Times are single runs on one PC and only show the order of magnitude. Three patterns are worth taking away:

  1. Bigger XPRESS chunks help a little. Each step from 4K to 8K to 16K saved a bit more.
  2. LZX is a clear step beyond XPRESS on data that compresses at all, and about ten times slower to compress here.
  3. Random data did not shrink at all, with any algorithm. WOF kept those files stored as they were.

Why some games barely shrink

Brawlhalla freed 22 MB out of about 1.4 GB. The same kind of result shows up with many games, for a few reasons:

  • The data is compressed already. Video, most audio formats and many engines’ packed archives are compressed when the game is built. Compressing them again finds almost nothing, exactly like the random data above. A game that ships most of its data this way has little left to give.
  • Some formats are dense by design. Block-compressed textures, the kind GPUs read directly, are already reduced to a fixed size, and general-purpose compression usually gains less on them than on text or code.
  • Tiny files cannot shrink much. Disk space is allocated in clusters, usually 4 KB, so a file that already fits in one cluster saves nothing by being compressed.
  • Parts of the game were compressed before. If you or a tool already compressed the folder, a second run skips those files, and the savings you see are only for the rest.

The opposite case, a game that frees a quarter to a third of its size, usually has a lot of uncompressed data: executables and libraries, scripts, configuration and localisation text, or raw asset files.

You cannot tell which kind a game is from its size. Either compress it and look at the result, or use a tool that samples the files first. ShelfSpace does that with a low–high estimate per game, and CompactGUI shows results that other users submitted for Steam games.

How to choose

  • Start with LZX for games you keep installed and play for a while. The extra compression time is paid once, and it saves the most.
  • Use XPRESS8K or XPRESS16K if you want a quick pass over a big library, or if you have a slow CPU and would rather keep the read-time cost low. XPRESS4K, the default, saves the least.
  • Skip games that barely shrink. If a game gains a few percent, there is no reason to keep it compressed.
  • Switch when in doubt. Recompressing with another algorithm needs /f, because compact skips files that are already compressed: compact /c /s /a /i /f /exe:xpress8k "...\GameFolder\*".
  • Undo for any game that feels worse: compact /u /s /a /i /exe "...\GameFolder\*".

The step-by-step commands, including how to check the result, are in How to shrink installed Steam games with compact.exe.

Sources

The game results are our own measurements with LZX. The synthetic table was measured by us with compact.exe on generated files in a scratch folder, never on a game install.