PyInstaller Decompiler Online

For packaged Python modules, type stubs, dependencies and native libraries in a .whl, use the Python Wheel Viewer and WHL Extractor. It preserves package contents without installing them.

What PyInstaller Puts Inside an Executable

PyInstaller combines a native bootloader, a Python interpreter, extension modules, and the application's compiled .pyc files. The payload is a CArchive appended to the launcher. A distinctive cookie near the end of the file points to its table of contents, which is why the same detection works for Windows, Linux, and macOS builds.

The original formatting and comments are not present in bytecode, but function names, constants, imports, control flow, and often local variable names remain. That is normally enough to reconstruct useful Python source.

Uploading a PYZ Archive On Its Own

Running a tool such as pyinstxtractor on an application leaves a folder containing PYZ-00.pyz — the compressed module store where nearly all of the program actually lives. That file can be uploaded here directly. It is read from its own header: the four bytes PYZ\0, the magic number of the interpreter that froze it, and a table of contents addressing one zlib-compressed module each.

Each recovered module is written out as an ordinary .pyc. PyInstaller stores modules without a header, so the header is rebuilt from the archive's own magic number rather than from whatever Python happens to be installed on the server — an archive frozen by Python 3.8 produces Python 3.8 bytecode. Modules that cannot be decompressed, which is what an archive frozen with PyInstaller's --key option looks like from outside, are named individually and never discard the modules that were readable.

Python Zipapps

A .pyz file is just as likely to be a PEP 441 zipapp, which is an entirely different thing: a plain ZIP archive with __main__.py at its root, sometimes preceded by a #! line so it can be run directly. The two formats are told apart by their bytes, not their extension.

There is usually nothing to decompile in a zipapp — it normally contains the developer's own .py source, which is preserved exactly as packaged. Any .pyc file with no packaged counterpart is decompiled, and everything else is kept under resources/ so the whole bundle stays browsable and downloadable.

The PYC Header Problem

PyInstaller strips the normal header from some entry-point modules. Sending those bytes directly to a Python decompiler either fails or, worse, selects the wrong bytecode format. After extraction this service verifies every module and repairs a bare code object with the complete header from an intact sibling in the same archive.

PyInstaller vs py2exe vs Nuitka

• PyInstaller stores modules in an appended CArchive and usually a compressed PYZ archive. It works on Windows, Linux, and macOS.
• py2exe is Windows-only. Its startup scripts live in a PE resource named PYTHONSCRIPT; larger builds often add a ZIP containing the rest of the modules.
• Nuitka compiles through C to native code. There is no equivalent module archive to unwrap, so automatic recovery to Python source is not possible.

What the Result Contains

Every recovered bytecode file is kept under pyc/, even when source decompilation fails. Successful modules appear under sources/ with the extracted package structure preserved. DECOMPILATION-NOTES.txt records the detected Python version, header repairs, encrypted or unsupported archives, and individual files the bytecode decompiler could not handle.

Python bytecode changes between interpreter releases. For a version newer than the installed decompiler supports, the service preserves the raw modules and says which version was found rather than returning misleading source.

Frequently Asked Questions