upx.github.io

An executable packer compresses a program file itself — not a folder you unzip later — so the program stays directly runnable while taking up less space. UPX (the Ultimate Packer for eXecutables) is a free, open-source packer that typically shrinks programs and DLLs by about 50%–70%, supports Windows programs and DLLs, macOS apps, and Linux executables, and decompresses in place at load time without a runtime or memory penalty for most supported formats.

Packing vs. archiving: the core difference

A Zip archive and a UPX-packed binary both get smaller, but only one is still a program.

With an archive, the compressed data sits beside the program. With packing, the compressed data is the program, wrapped in a small loader that restores it in memory when it starts.

How UPX compresses a program

UPX works on the executable file format itself. It compresses the code and data sections, then attaches a decompression stub and the information needed to rebuild the original layout. When the packed program launches, that stub decompresses the sections back into memory in place, and execution continues as before.

The homepage describes the result this way: programs and libraries compressed by UPX are "completely self-contained and run exactly as before, with no runtime or memory penalty for most of the supported formats." Decompression is fast — the project cites more than 500 MB/sec on any reasonably modern machine — so startup impact is minimal for typical binaries.

A concrete example: a 10 MB Windows DLL packed with UPX at a 60% reduction becomes roughly 4 MB on disk. You ship the 4 MB file; when a program loads it, the stub expands it in memory and the DLL behaves like the original. The savings show up in download size, disk footprint, and distribution cost — not in a slower-running program.

What you get beyond compression

UPX is built to be reversible and checkable, which matters when you are modifying binaries:

• List — inspect a packed executable's contents and metadata.
• Test — verify the packed file is intact.
• Unpack — restore the original executable.
• Checksums — a checksum of both the compressed and uncompressed file is maintained internally, so corruption is detectable.

These operations mean packing is not a one-way door: you can confirm what a file contains and recover the original.

Trade-offs and when not to pack

Packing changes a binary's on-disk signature, and that has practical consequences:

• Antivirus false positives. Packed executables are a common malware disguise, so some scanners flag packed files heuristically. UPX's answer is transparency: because it has been documented open source for years, security and antivirus software can look inside UPX-compressed apps to verify them. That helps, but it does not guarantee every scanner on every system will stay quiet — test against the tools your users actually run.
• Debugging and forensics get harder. A packed binary is not the original; stack traces, symbol tools, and manual inspection see the compressed form until you unpack.
• Not every file benefits. Already-compressed payloads, very small executables, and files where startup latency is critical may gain little or nothing. Measure before shipping.
• Distribution rules still apply. Packing does not change a program's license or signing requirements; check those separately.

Who UPX is for

UPX fits when you distribute executables and want smaller downloads and installs without changing how the program runs: shipping Windows utilities and DLLs, trimming Linux binaries for containers or embedded images, or reducing macOS app size. It is less suitable when a binary must remain byte-identical for signing or audit, when scanners in your environment are strict about packed files, or when the size saving is marginal.

UPX is free software under the GNU GPL v2+, with license terms that permit free use with commercial applications as stated in the UPX License Agreement, and full source code is available.

An executable packer compresses a program or DLL and attaches a small self-contained decompression stub, so the file takes less space on disk and in transit but still starts and runs like the original. UPX, the Ultimate Packer for eXecutables, is a free, open-source packer that typically shrinks programs and DLLs by around 50%–70%, and for most supported formats the packed program runs with no runtime or memory penalty. The trade-offs to weigh are compatibility with your target formats and how packing interacts with signing and security tooling, not day-to-day speed.

How packing works

Packing happens in two layers:

1. Compression. The original executable's code and data are compressed with one of UPX's algorithms (NRV, UCL and others). The compressed payload is stored inside the file.
2. A decompression stub. A small bootstrap routine is embedded in the packed file. When the operating system loads the executable, the stub runs first, decompresses the original program, and hands control to it.

Because the stub and the compressed payload travel together, the packed file is completely self-contained. You do not need UPX installed on the machine that runs it, and the program behaves exactly as before.

Why there is no memory overhead

UPX decompresses in place: the original program is reconstructed in the same memory region the packed file already occupies, rather than allocating a second buffer. That is why the UPX documentation states there is no memory overhead for compressed executables on most supported formats, and why decompression is fast — the project cites more than 500 MB/sec on any reasonably modern machine.

A useful way to picture it: think of a flat-pack furniture box. The box (packed file) is small for shipping, and the assembly instructions (stub) let you build the full item (original program) on arrival — but you build it in the same spot where you unpacked it, so you don't need extra floor space.

What you gain

What to check before you pack

• Supported formats. UPX covers Windows programs and DLLs, macOS apps and Linux executables, but not every binary you might encounter. Confirm your target format is supported before planning a release around packing.
• Signing and integrity checks. Packing changes the file bytes, so any signature or hash computed over the original no longer matches the packed file. Plan for re-signing or re-hashing after packing.
• Security and antivirus behavior. UPX is long-documented open source, and the project notes that relevant security and antivirus software can inspect UPX-compressed apps. Still, packed binaries attract more scrutiny than unpacked ones, so test in your actual deployment environment.
• Reversibility. UPX can list, test and unpack executables, and it keeps internal checksums of both the compressed and uncompressed file. That makes packing a reversible step you can verify rather than a one-way transformation.

A concrete scenario

Suppose you ship a desktop application with a large DLL. You pack the DLL with UPX before building your installer. The installer and download are smaller, users get the file faster, and when the application loads the DLL, the stub decompresses it in place — the app sees the same library it always did. If a user reports a problem, you can unpack the DLL and compare checksums to confirm the payload is intact.

Bottom line

Use an executable packer like UPX when distribution size and transfer cost matter and your binaries are in supported formats. Expect roughly 50%–70% smaller files, normal startup behavior and no memory penalty for most formats. Budget time for re-signing packed binaries and for testing them against your security tooling — those are the practical costs, not runtime performance.

UPX (the Ultimate Packer for eXecutables) is a free, open-source executable compressor that shrinks programs and DLLs by roughly 50%–70%. The packed file stays self-contained and runs exactly as before, with no runtime or memory penalty for most supported formats. It is a practical choice when you want smaller downloads, less disk usage, or lower distribution costs, and it supports Windows programs and DLLs, macOS apps, and Linux executables.

What UPX actually does

UPX compresses an executable file and attaches a small decompression stub. When the program starts, the stub decompresses the original code in place and hands control to it. Because decompression happens in place, the compressed executable does not need extra memory beyond what the original program used — for most supported formats.

The homepage describes decompression as very fast (over 500 MB/sec on any reasonably modern machine) and the compression ratio as typically better than Zip. That combination is the core trade-off UPX offers: smaller files on disk and over the network, with startup work shifted to a fast in-place decompression step.

Supported targets

The exact format list is not enumerated on the homepage, so check the release documentation for the specific binary type you plan to pack.

Is it safe to use?

The homepage makes several safety claims worth understanding:

• Open source transparency. UPX has been documented open source for many years, so relevant security and antivirus software can inspect inside UPX-compressed apps to verify them.
• Reversible operations. You can list, test, and unpack your executables, so packing is not a one-way door.
• Integrity checks. A checksum of both the compressed and uncompressed file is maintained internally.

One practical caveat follows from how packers work in general: some antivirus and endpoint tools treat packed binaries with extra suspicion, and packed executables can trigger heuristic flags even when clean. The homepage's point is that UPX's long-standing open documentation lets security software look inside — not that packing is invisible to scanners. If you distribute packed binaries, test them against the security tooling your users actually run.

Licensing and commercial use

UPX is distributed with full source code under the GNU General Public License v2+ — either pure GPLv2+, or at your option GPLv2+ with special exceptions and restrictions. Per the UPX License Agreement as described on the homepage, UPX may be distributed and used freely, even with commercial applications. If licensing terms matter for your product, read the full license agreement rather than relying on the summary.

When UPX is a good fit — and when it isn't

Good fit:

• You ship large executables or DLLs and want to cut download size and distribution cost.
• You want a mature, portable, extendable packer with source available.
• You need to pack, verify, and unpack binaries as part of a build or release process.

Think twice:

• Your users' security stack is aggressive about packed binaries and you cannot test against it.
• You need a documented, guaranteed list of supported formats before committing — verify your specific target first.
• Startup latency is extremely sensitive; in-place decompression is fast, but it is still work that happens at launch.

Getting started

1. Download the latest release from the UPX homepage (a GitHub source link is also provided there).
2. Pack a copy of your binary — never your only copy — and confirm the packed file runs identically.
3. Use UPX's list and test functions to verify the packed executable before distributing it.
4. Keep the ability to unpack, so you can return to the original binary if a target environment rejects the packed version.

The expected result is a smaller file that behaves like the original; the verification step is what confirms it for your specific program and platform.