Windows already compresses games. When to use the free tool.

When you install a 100 GB game on a half-full SSD, the question is not whether you can free space. The question is which tool to use. Windows ships with compact.exe, a command-line program that applies LZX compression to any folder of files. A handful of paid and free third-party tools wrap the same algorithm in a clickable interface. Both approaches produce the same compressed files on disk. The differences show up in workflow, not output.

This is a decision guide for the operator who has a few big games installed and a finite amount of free space. The goal is to pick the right tool for the way you actually play.

What compact.exe does, and why games are a good target

NTFS, the default Windows file system (the format Windows uses to organize files on a drive), supports per-file compression. Each file can be marked as compressed or uncompressed, and the file system itself handles the work of squeezing and unsqueezing bytes on the fly. Older Windows releases used a slow algorithm. Modern Windows ships compact.exe with several faster algorithms. The one called LZX is the same algorithm the popular Steam tools use. It trades a small amount of CPU on read for a meaningful reduction in disk size.

Games are a sweet spot for this feature for three reasons:

• Reads dominate writes. A game installs once and reads thousands of files per session. The compressed-file overhead (the small amount of extra CPU work NTFS does to decompress each file as the game opens it) is invisible compared to the GPU work the game is already doing.
• DirectStorage is the exception, not the rule. A small set of recent games stream assets directly from a fast NVMe drive (a Solid State Drive plugged into the motherboard’s high-speed slot) using Microsoft’s DirectStorage API (a Windows feature that lets the GPU pull compressed data straight from disk). Compressing those specific files breaks the streaming path. Most games still do not use DirectStorage.
• Storage gains are large. A typical game folder shrinks by 30 to 50 percent with LZX. A 100 GB install becomes 60 to 70 GB on disk, with no change to what the game sees.

The trade-off is CPU. Older CPUs and very slow hard drives can show a hitch when the game first opens a compressed file. On any system built in the last five years, the hitch is in the milliseconds.

When the command line is the right answer

compact.exe ships with every modern Windows install. The interface is a single command run from an elevated Command Prompt (a command-line window opened with administrator privileges) or PowerShell. The general shape is:

compact.exe /c /s:"PATH\TO\GAME" /i /exe:lzx

The flags are:

• /c tells the tool to compress what it finds.
• /s:PATH scopes the operation to one folder and everything beneath it.
• /i keeps the compression running even if a single file fails.
• /exe:lzx selects the LZX algorithm. The XPRESS4K and XPRESS8K flags are faster but produce smaller savings. XPRESS16K is the middle option.

To undo the compression, the operator replaces /c with /u. The algorithm can also be changed on the fly by re-running the command with a different /exe flag.

The command-line path is the right answer in three situations:

• One or two big games, infrequent updates. Run the command once, walk away, and the savings stick. New patches do occasionally rewrite files and lose the compressed flag on the rewritten copies; running the same command again after a major patch handles that.
• Headless servers and unattended installs. A scripted install of an unattended game server can include the compact.exe line in the same script that copies the game files. No GUI is needed.
• A preference for tools that are already installed. compact.exe is part of Windows. There is nothing to download, nothing to update, and nothing to break if the developer of a third-party app stops maintaining their product.

The catch is friction. The operator has to know the install path of every game, has to keep a list of those paths, and has to remember to re-run the command after big patches. For a single Steam library, that is manageable. For a mixed library spanning Steam, EA, GOG, and Xbox, the manual list grows fast.

When a GUI wrapper earns its keep

A handful of paid and free tools wrap compact.exe in a clickable interface. Game Compressor on Steam is one of the better-known paid examples. CompactGUI is the well-known free example. Both do the same underlying work as the command-line tool. The differences show up in discovery and update handling.

A GUI wrapper is the right answer in four situations:

• Many games across many launchers. The wrapper scans the install paths of each launcher it knows about, lists every game it finds, and lets the operator pick which to compress. Manual path entry drops out of the loop.
• Automatic update detection. After a game patch, the wrapper rescans and flags games that have files no longer marked compressed. The operator gets a one-click “recompress these” action.
• DirectStorage exclusion. The well-built wrappers know to skip games that use Microsoft’s DirectStorage asset pipeline, because compressing those games would hurt load times. The command-line user has to keep that exclusion list by hand.
• A preference for visual confirmation. The wrapper shows before-and-after sizes, percentage saved, and which games still need work. The command-line user gets a stream of text and has to interpret it.

The trade-off is a small recurring cost. Paid wrappers charge a few dollars once. Free wrappers are open source and accept donations. Neither is expensive. The real cost is the install: another program that ships updates, that has to be compatible with the current Windows release, and that may eventually be abandoned by its developer.

Trade-offs

Both paths produce the same compressed files on disk. Neither path changes the game itself. The differences are operational, not technical.

• Command-line cost is operator attention. Every game added or removed means an edit to the operator’s mental or written list of paths. Patches require remembering to re-run the command. This is a low one-time cost that compounds over years.
• GUI wrapper cost is dependency trust. The wrapper has to be installed, kept current, and trusted to keep working as Windows changes. A small dependency, but a real one. The operator is trusting an outside developer to maintain the integration with each game launcher.
• DirectStorage is the wildcard. The set of games using DirectStorage grows each year. Both paths need to keep an exclusion list. The command-line operator maintains it manually. The wrapper maintains it automatically, but only if the wrapper’s developer keeps current.
• CPU cost is real but small. On any system from the last five years, the decompression overhead during gameplay is unmeasurable. On a ten-year-old laptop with a hard drive instead of an SSD, the overhead is visible during loading screens. The fix is hardware, not a different tool.
• Reversibility is complete. Switching tools is a one-time cost. Switching back to an uncompressed install is also a one-time cost. Either tool can undo the other tool’s work in a single command.

If the library has fewer than ten games and updates are infrequent, the command line is the right answer. If the library spans multiple launchers, updates arrive weekly, and the operator values a visible queue of what still needs compression, a GUI wrapper earns its keep. The wrong answer is paying for a wrapper to compress one game once.