UPX shrinks binaries, refuses to encrypt them, and only wants trusted input

The project rules out protection and encryption on purpose

The forward looking section of the README is short and unusually firm. The first commitment is staying current with ongoing operating system and executable format changes, which is the part that matters most for a packer that has to keep parsing formats that vendors keep changing. The second commitment is a refusal: the project states it will not add any sort of protection or encryption, and gives the reason, that this only gives people a false feeling of security because all protectors can be broken by definition. That is a design position, not a missing feature waiting for a patch. The practical consequence is direct: if you picked UPX because you wanted a binary to be harder to read or to reverse, you picked the one tool whose maintainers have promised in writing never to do that, and a wrapper such as a self extracting installer that relies on the payload being opaque is building on a premise the upstream project rejects.

Listing a file is treated as the same risk as executing it

The security section states the rule in one line and then repeats it in a way that changes how you should automate the tool. UPX inherits the security context of any files it handles, which means packing, unpacking, or even testing or listing a file requires the same security considerations as actually executing the file. The instruction that follows is to use UPX on trusted files only. Reading that carefully, the parsing of a file format is treated as untrusted input handling, so the read only operations are not safe operations. That has direct consequences for pipelines: a build system that unpacks every artifact it receives, or a scanner that runs the tool in listing mode over a directory of uploaded samples, is doing the equivalent of executing them. The README does not name the flag used for listing, pointing instead to the full documentation in doc/upx-doc.txt, so anyone writing such a pipeline has to confirm the exact invocation there first.

The size claim comes with a hedge about formats

The headline number is that UPX typically reduces the file size of programs and DLLs by around 50 to 70 percent, and the stated benefit is less disk space, shorter network load and download times, and lower distribution and storage cost. The runtime claim is where the hedge sits. Packed programs and libraries are described as completely self contained and running exactly as before, with no runtime or memory penalty for most of the supported formats. Most, not all, and no figure is given for the ones left out, so a benchmark on your own build is the only way to learn which side of that line your target falls on. The format coverage named in the README is Windows programs and DLLs plus Linux executables, described more generally as a number of different executable formats. Basic usage compresses a program directly, and two options exist for the best results.

upx program.exe
upx --best program.exe
upx --brute program.exe

The top level Makefile is a wrapper that caches its CMake configure step

Building UPX goes through CMake, and the Makefile at the top of the repository is described in its own header as a convenience wrapper for calling CMake. It needs GNU make and CMake 3.13 or newer, and it sets the default goal to build/release, with build/debug, debug, release, all and a wildcard target that fans a directory out into both configurations. The detail worth knowing is in the config rule, which checks for an existing CMakeFiles stamp file matching the pattern .*_cmake_config_done.txt in the build directory and skips the configure call entirely if it is there, with a comment saying it avoids re-running the config. The consequence is that the configure step is sticky. Change a flag, a compiler or a toolchain and the wrapper will keep the cached configuration, so a stale build directory produces a build you did not ask for, and the fix is to remove the directory rather than re-run the target. Two other knobs are visible: VERBOSE adds a verbose makefile variable, and a Ninja generator line is present but commented out.

The manual CMake path re-runs configure every time

For anyone stuck with an older CMake 3.x, the Makefile header carries an explicit hint for invoking CMake by hand, and the sequence is short enough to be the fastest way to see what the wrapper is doing.

mkdir -p build/release
cd build/release
cmake ../..         # run config
make -j4            # and run build

Three things differ from the wrapper. The build directory is created and entered by hand, configure runs unconditionally on every invocation instead of being guarded by the stamp file check, and parallelism comes from make -j4 rather than from the cmake --parallel flag the wrapper passes, which is also why the wrapper declares itself not parallel. The build itself is driven by CMakeLists.txt at the repository root, and the parallel build flag is added to UPX_CMAKE_BUILD_FLAGS, while the CMAKE variable names the cmake binary the wrapper calls. A C++ toolchain is the real prerequisite here, and the repository ships .clang-format, .clang-tidy and .clangd files alongside a vendor directory and a .gitmodules file.

Two license files, and the repository metadata reports NOASSERTION

The copyright and license section is where the dual licensing lives. UPX is distributed with full source under GNU General Public License v2+ either under the pure GPLv2+, which is the file COPYING, or at your option under the GPLv2+ with special exceptions and restrictions that grant free usage for all binaries including commercial programs, which is the file LICENSE. The same section says you should have received a copy of the license agreements with the program and that the two files are the place to read them. The license field on the repository reports NOASSERTION, and the terms are a choice between two files rather than a single canonical license text, and picking wrong for a commercial distribution is a legal question rather than a build error. The README also states plainly that UPX may be distributed and used freely, even with commercial applications, and separately that the program comes without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose.

The name is a disclaimer about trademarks, not a product line

The final note in the README is a short legal clarification with a practical effect. The term UPX is a shorthand for the Ultimate Packer for eXecutables, and it holds no connection with potential owners of registered trademarks or other rights. Since the acronym is short and already in heavy use across unrelated software categories, the practical consequence is that a bare search for the four letters lands on products that have nothing to do with a packer, so the only reliable identifiers are the site at upx.github.io and the repository itself. On the code side, the project is C++ with the copyright line running from 1996 to 2026 across Markus Franz Xaver Johannes Oberhumer, Laszlo Molnar, and John F. Reiser. The default branch is devel, the newest tag is v5.3.0 from 2026-10-28, and the last push landed on 2026-11-02, so the release line and the development branch are not the same thing when you go looking for a fix.

Editorial conclusion

UPX earns its place when you control the binaries and want smaller downloads or less disk used, on the formats it handles well and without caring about obfuscation. It is the wrong tool the moment your goal is concealment, since the project rules out protection and encryption on principle, and the wrong tool on any pipeline that touches binaries you did not build, since listing alone is treated as execution grade risk. Before you adopt it, confirm your target format is one it supports, decide whether --best is worth the time for your build, and keep the GPLv2+ question settled by reading which of COPYING or LICENSE governs the distribution you are making.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. upx/upx on GitHub