Convert Python to EXE: A Real PyInstaller Walk-Through

There are a few packagers (Nuitka, cx_Freeze, py2exe), but PyInstaller is the one most people mean by "py to exe." It works by bundling the CPython interpreter, your script's compiled bytecode, and every library it imports into one distributable. Install it with pip:

pip install pyinstaller

Here's the tiny script I packaged — a stand-in for a real CLI tool, with an import so the bundle has something to pull in:

import hashlib
import sys

def fingerprint(text):
    return hashlib.sha256(text.encode()).hexdigest()[:16]

def main():
    name = sys.argv[1] if len(sys.argv) > 1 else "world"
    print(f"Hello, {name}!")
    print("fingerprint:", fingerprint(name))

if __name__ == "__main__":
    main()

One command does it. --onefile collapses everything into a single executable:

$ pyinstaller --onefile greeter.py
INFO: PyInstaller: 6.21.0
INFO: Python: 3.14.2
INFO: Building PYZ (ZlibArchive) ... completed successfully.
INFO: Building EXE from EXE-00.toc completed successfully.

$ dist\greeter.exe Mithun
Hello, Mithun!
fingerprint: 7f6c499c46b87f83

That's the whole thing: a dist/greeter.exe that runs on a Windows box with no Python installed, producing the exact same output as the script. For a lot of use cases — a utility for a non-technical client, an internal tool, a game script — that's all you need.

PyInstaller has two output modes, and the difference is real. I built the same script both ways and measured:

--onefile is tidier to hand over (literally one file), but it unpacks itself into a temporary folder each time it runs, so it starts slower and can trip antivirus. --onedir is bulkier and "messier" (a folder of files) but launches faster and is easier to debug. For a double-click-and-share tool I use onefile; for something launched often, onedir.

This is the big one, and it's why you should be suspicious of any website that claims to "convert Python to exe" from your browser: PyInstaller cannot cross-compile. To build a Windows .exe you must run PyInstaller *on Windows*; a macOS .app must be built on macOS; a Linux binary on Linux. There is no flag that turns a Linux server into a Windows-exe factory.

So a real online "py to exe" service can't just run PyInstaller on one Linux box — it needs an actual Windows machine to build on. That's exactly how our Python to EXE tool works: instead of faking it, it generates a GitHub Actions workflow that builds your executable on real Windows, macOS, and Linux runners and hands you the artifacts. Same PyInstaller, but on genuine per-OS machines — the only honest way to do it in the cloud.

• Antivirus false positives. A self-extracting --onefile exe from an unknown publisher looks, to a heuristic scanner, a lot like malware. Unsigned exes get flagged. Code-signing or shipping --onedir reduces this.
• Missing modules at runtime. PyInstaller finds imports by static analysis, so anything imported dynamically (importlib, plugins, some libraries) may be left out. The fix is --hidden-import modulename or a hook.
• Data files not found. Bundled images/configs need --add-data, and your code must locate them via the sys._MEIPASS temp path at runtime, not a relative path.
• Size. Every heavy dependency (pandas, numpy, PyQt) balloons the exe. --exclude-module and a clean virtualenv keep it down.

This is the part that matters if your script has valuable logic or secrets. Packaging to .exe feels like it hides your code. It doesn't. I searched the real onefile exe I'd just built for tell-tale strings:

greeter      -> FOUND
PyInstaller  -> FOUND
_MEIPASS     -> FOUND
python314    -> FOUND

Those markers (_MEIPASS is PyInstaller's runtime-extraction path) instantly identify it as a PyInstaller-packed Python app. And in --onedir, the _internal/ folder literally contains python314.dll and base_library.zip sitting in the open. A tool called pyinstxtractor unpacks that archive straight back into .pyc bytecode files — and as I showed when I decompiled a .pyc, that bytecode leaks your strings and decompiles to near-original source.

That's the workflow we'd recommend: run your script through the Python Obfuscator (AST renaming, string encryption, and up to a fully encrypted wrapper), *then* build the .exe. Now even if someone unpacks the exe and decompiles the bytecode, what they get back is the obfuscated version — not your real code.