Fix "Bad Magic Number" in a Python `.pyc` File

Every .pyc starts with a 4-byte magic number that identifies the exact CPython version that compiled it. When the interpreter loads a .pyc, it checks those bytes first; if they don't match its own, it stops immediately rather than run bytecode it might not understand. Loading a Python 3.11 .pyc under Python 3.14, for example, gives:

ImportError: bad magic number in 'h': b'\xa7\r\r\n'

Those four bytes — \xa7\r\r\n, i.e. a7 0d 0d 0a — are the give-away: the leading a7 is the 3.11 magic, and 0d 0a is a constant \r\n trailer every version shares. The file is fine; it just needs a 3.11 interpreter. bad magic number never means the .pyc is corrupt or somehow locked — only that the *version* doesn't match.

I read importlib.util.MAGIC_NUMBER from each real interpreter (via the official python:<ver>-slim images) so this table is measured, not copied. The magic is a little-endian 2-byte integer followed by the constant 0d 0a, which together make the 4 header bytes:

You don't need any tools to read the version — the first two bytes are enough. Open the file in binary mode, take the little-endian integer, and look it up:

import sys

MAGIC = {3413: "3.8", 3425: "3.9", 3439: "3.10", 3495: "3.11",
         3531: "3.12", 3571: "3.13", 3627: "3.14"}

with open(sys.argv[1], "rb") as f:
    head = f.read(4)

n = int.from_bytes(head[:2], "little")
print("first 4 bytes :", head.hex(" "))
print("magic int     :", n)
print("compiled by   : Python", MAGIC.get(n, "unknown/other"))

first 4 bytes : a7 0d 0d 0a
magic int     : 3495
compiled by   : Python 3.11

Prefer not to touch the shell? Drop the .pyc into our free .pyc Decompiler — it reads the magic number for you and shows a Python 3.11 · clean recovery badge (and does the same for 3.8 through 3.14), then decompiles the file in the same step.

1. Version mismatch (by far the most common). The .pyc was built on a different Python than you're running. Identify the version from the table above, then run the file with a matching interpreter — pyenv install 3.11 / uv python install 3.11, or a python:3.11 Docker image. If you have the original .py, the simplest fix is to just delete the stale .pyc (or the whole __pycache__/) and let Python recompile it for your version.
2. A moved or rebuilt environment. Copying __pycache__ between machines, or changing a Docker base image (e.g. python:3.11 → python:3.12), leaves .pyc files from the old version. Clear __pycache__ and reinstall/rebuild so everything is recompiled locally.
3. A `.pyc` extracted from a PyInstaller app. pyinstxtractor gives you .pyc files that need the *same* Python the app was frozen with, and older PyInstaller versions strip the header so tools can't even read the magic. If that's your case, see decompile a PyInstaller EXE for rebuilding a valid header.
4. A truncated or corrupted file. If the header is a version you *do* have but you still get an error, the body may be damaged. A short or garbled code object surfaces as a marshal error rather than a magic error:

EOFError: marshal data too short

Variants like bad marshal data (unknown type code) or bad marshal data (invalid reference) mean the same thing: the header matched, but the serialized code object after it is incomplete or mangled. Re-extract or re-download the file; there's nothing to "fix" in a byte-damaged .pyc.

If you can't get the matching interpreter and you don't have the original .py, the practical move is to recover the source from the .pyc itself. Our in-browser .pyc Decompiler runs pycdc (Decompyle++) via WebAssembly and returns readable Python for 3.0 through 3.12 (partial for 3.13) — with no install and the version detected for you. For 3.13/3.14 bytecode that full decompilers don't rebuild yet, the standard library's marshal + dis still read the strings and logic on any version — the tested method is in can you decompile a Python 3.14 .pyc.