Online pyc Decompiler — Decompile .pyc to Python (2.x–3.14)
Decompile a compiled Python .pyc back to readable source — Python 2.x through 3.14, with the version detected automatically. Most files decompile in about a second.
Why use this tool?
Use the .pyc Decompiler to see exactly how much a compiled Python file gives away. Drop in a .pyc and it reconstructs readable source — variable names, string literals and the shape of the logic — for every Python version from 2.x to 3.14. Output is best-effort (review before trusting it), but it's the fastest way to prove to yourself that shipping .pyc is not protection.
Drop a .pyc here, or click to choose
Max 8 MB (3 MB for Python 3.13+).
Samples are Python 3.9 bytecode — watch the source (variable names, strings and all) come straight back.
Recovers source for Python 1.x through 3.14. Most files come back in about a second; Python 3.13 and newer get a deeper reconstruction pass that takes a little longer. Output is best-effort — names and strings usually come back accurately, but control flow can be reconstructed incorrectly, so review and test recovered code before running it. Use it to inspect your own compiled Python and see how little a .pyc actually hides — then obfuscate so it can't be read back. See also: why .pyc isn't protection.
A license check inside a .pyc can be read — and patched out.
Obfuscation makes the source harder to read, but any check baked into the code can still be found and bypassed once someone decompiles it. Licers verifies each license against a server with Ed25519-signed responses and binds it to a device — so even a cracked, fully de-obfuscated copy still can't forge a valid license.
Tool facts
- Supported Python
- Python 2.x – 3.14 .pyc bytecode
- Input limit
- Max file: 8 MB (3 MB for Python 3.13+ files)
- Last reviewed
- 2026-09-26
What it can't do
- •Recover original comments or formatting — those aren't stored in a .pyc (docstrings usually survive, unless the file was compiled with -OO).
- •Guarantee correct output — decompilation is best-effort; control flow and optimized expressions can be reconstructed incorrectly, so review and test recovered code.
- •Decompile files encrypted or packed by tools like PyArmor.
About Python .pyc Decompiler
Most Python decompilers are limited: the popular pure-Python tools (uncompyle6, decompyle3) only cover up to Python 3.8–3.9 and won't even run on newer interpreters. Our decompiler covers Python 2.x through 3.14. Most files come back in about a second. Python 3.13 and 3.14 files — and any file that needs it, such as some 3.12 async code — automatically get a deeper reconstruction pass that rebuilds the source statement by statement and checks each function by recompiling it and comparing the bytecode. That pass usually takes from 30 seconds to 2–3 minutes, depending on the size of the file. Either way you get usable source even on versions the pip-based decompilers can't touch at all.
Drop a .pyc file and you get recovered .py source back, including variable names and string literals. It's a best-effort reconstruction: names and constants usually come back accurately, but control flow and optimized expressions can be reconstructed incorrectly, so always review and test recovered code before running it. When a function can't be rebuilt exactly (match/case and some try/except blocks are the usual suspects), the page tells you the result is partial. Because a .pyc gives up this much this easily, the takeaway is simple: to actually protect Python, obfuscate the source first so even the decompiled bytecode is unreadable.
Learn more: our Python .pyc decompiler guide explains how decompilation works, how to decompile a .pyc step by step walks through it with real output, and if Python won't load a .pyc at all, fix the "bad magic number" error with our tested magic-number table for Python 3.8–3.14.
See it decompile a real .pyc (tested)
Here's an actual run through this page's decompiler. We took a small license-check script, compiled it to a Python 3.11 .pyc, and fed that .pyc (not the source) to the decompiler. This is the unedited output.
import sys
API_KEY = "sk-9f3a-PRO-2026"
def check_license(code):
valid = {"PRO-2026-XYZ", "TRIAL-7788"}
return code in valid
def main():
if len(sys.argv) < 2 or not check_license(sys.argv[1]):
print("Invalid or missing license key")
sys.exit(1)
print(f"Licensed. key={API_KEY}")
if __name__ == "__main__":
main()# Decompiled with https://pyobfuscate.com
import sys
API_KEY = 'sk-9f3a-PRO-2026'
def check_license(code):
valid = {
'PRO-2026-XYZ',
'TRIAL-7788'}
return code in valid
def main():
if not len(sys.argv) < 2 or check_license(sys.argv[1]):
print('Invalid or missing license key')
sys.exit(1)
print(f'''Licensed. key={API_KEY}''')
if __name__ == '__main__':
main()Everything sensitive comes back in plain text
The hard-coded API_KEY, both license codes, the function and variable names, and the structure of the logic all come straight back — from the compiled .pyc alone. That's the point: shipping .pyc (or freezing to an .exe, which just bundles .pyc) hides none of this. To actually protect the logic, obfuscate the source first so even the decompiled result is unreadable.
It's best-effort — review before you trust it
Look at the main() condition: the decompiler reconstructed it as if not len(sys.argv) < 2 or check_license(...), but the original was if len(sys.argv) < 2 or not check_license(...) — those aren't logically equivalent, so the boolean was recovered *wrong*. Names, strings and overall structure are usually accurate, but control flow and optimized expressions can be rebuilt incorrectly. So recovered code is for reading and understanding — never run it without carefully reviewing and testing it against the original behavior.
Frequently Asked Questions
Explore Other Tools
Python Bytecode Disassembler
Disassemble Python to CPython bytecode with the dis module — explore opcodes, code objects, jumps and constants. Runs in your browser.
Python Type Checker
Type-check your Python online with mypy — runs 100% in your browser via WebAssembly. Pick a target Python version (3.8–3.14) and strict mode.
Code to Flowchart
Turn Python code into a flowchart from the real AST — deterministic, no AI. Handles if, match, loops, try/except and async, with a control-flow-graph mode, unreachable-code highlighting, and Mermaid/SVG/PNG export.
requirements.txt → pyproject.toml Converter
Convert a requirements.txt (or requirements.in) into a pyproject.toml — runtime and dev dependency groups, with extras, version pins and environment markers preserved. Runs in your browser.