How to Decompile a Python `.pyc` File: Every Method, Tested

API_KEY = "sk-demo-7c1f2a"

def check(user, key):
    if key == "PRO-2026":
        return f"welcome {user}"
    return "access denied"

print(check("mithun", "PRO-2026"))

It has the two things people hope a .pyc hides: a hard-coded key and a bit of logic. Let's see how well it hides them.

If you just want the source back with zero setup, an online decompiler is the fastest path. Our free .pyc Decompiler runs pycdc (Decompyle++) compiled to WebAssembly, so it decompiles entirely in your browser — the file is never uploaded to a server. Drop the .pyc in and you get source out.

Here's the actual output it produced for the Python 3.12 build of the sample (this is the real pycdc result):

# Source Generated with Decompyle++
# File: input.pyc (Python 3.12)

API_KEY = 'sk-demo-7c1f2a'

def check(user, key):
    if key == 'PRO-2026':
        return f'''welcome {user}'''

print(check('mithun', 'PRO-2026'))

Near-perfect: the key, the function, the PRO-2026 check, the f-string — all recovered. One honest imperfection to notice: it dropped the final return "access denied" line. Decompilers occasionally miss an edge branch on newer bytecode, which is a useful reminder that decompilation is reconstruction, not a byte-perfect inverse.

For scripting and batch work, the classic tools are uncompyle6 and decompyle3, installed from pip. On the versions they support, their output is essentially the original file. I ran uncompyle6 on the Python 3.8 build (running it under Python 3.8 itself, via uv run):

# uncompyle6 version 3.9.3
# Python bytecode version base 3.8.0 (3413)
# Embedded file name: sample.py
# Size of source mod 2**32: 172 bytes
API_KEY = "sk-demo-7c1f2a"

def check(user, key):
    if key == "PRO-2026":
        return f"welcome {user}"
    return "access denied"

print(check("mithun", "PRO-2026"))

That's byte-for-byte the original, right down to the return "access denied" branch pycdc dropped — plus bonus metadata (the original filename and compile size) that uncompyle6 reads out of the header. The catch is version range: uncompyle6 tops out around Python 3.8, decompyle3 around 3.9. Point either at a 3.11+ .pyc and it won't even start. For newer bytecode you use the `pycdc` CLI (the same engine as the online tool, built from C++).

Here's the method people forget: you don't strictly need a decompiler at all. A .pyc is a 16-byte header followed by a marshal-serialized code object — the exact thing the interpreter runs. Python's own marshal and dis modules read it on any version, because it's the interpreter's native format. That makes this the universal fallback.

I pointed it at the Python 3.14 build — the one no decompiler above could handle yet:

import marshal, dis

with open("sample.cpython-314.pyc", "rb") as f:
    header = f.read(16)          # skip the 16-byte .pyc header (3.7+)
    code = marshal.load(f)       # the module's code object

dis.dis(code)                    # disassemble the logic
print([c for c in code.co_consts if isinstance(c, str)])

string constants recovered:
  ['sk-demo-7c1f2a', 'PRO-2026', 'welcome ', 'access denied', 'mithun', 'PRO-2026']

# dis excerpt — the license check, in the clear:
LOAD_CONST   3 ('PRO-2026')
COMPARE_OP  88 (bool(==))
LOAD_CONST   1 ('welcome ')

No decompiler, no matching interpreter, no internet — and the API key, the license string, and the exact comparison are all right there. You don't get clean .py back (you get bytecode + constants), but for finding secrets or understanding logic it's often all you need, and it never hits a version wall.

The single most important thing about decompiling a .pyc is matching the tool to the bytecode version. Here's what I actually observed testing the sample from 3.8 to 3.14:

In my run, the online/pycdc engine cleanly decompiled 3.8–3.12, returned a partial result on 3.13 (# WARNING: Decompyle incomplete), and rejected 3.14 with Bad MAGIC!. Decompiler support always lags new Python releases by a while — so for a brand-new version, Method 3 is your bridge until the tools catch up. (Decompiler version support is a moving target; "my version isn't supported yet" is a delay, not a defense — see decompiling a .pyc.)

Every method above recovers either your source or your secrets, so shipping .pyc instead of .py is not protection — it's a cache format. If the goal is to make a .pyc genuinely hard to read, the fix is to change what gets compiled in the first place:

1. Obfuscate the source before compiling. A decompiler can only give back the source that was compiled — so if you rename every identifier and encrypt the string literals first, the decompiled output is that mangled, encrypted version, not your real code. Our free Python Obfuscator does this at the AST level.
2. Keep real secrets off the client. As the tests show, a hard-coded key survives every format. Load keys from the environment or your own backend — see how to protect API keys in Python.
3. For the strongest bar, compile to a native module (.pyd/.so via Cython, or a Nuitka binary) so there's no bytecode to marshal.load at all. See Python to EXE.

More on the full picture in is Python obfuscation secure? and protecting Python source code.