Python Obfuscation Compatibility Matrix: 3.8–3.14, Tested

Each feature has a runnable fixture that prints a known result. It's obfuscated on the 3.11 engine (all layers: rename, string/int encoding, control-flow flattening, junk injection, import/attr/builtin hiding), then both the original and the obfuscated output are run on every version. "Obfuscated output runs" means it executed and produced the correct result.

The most common worry is that obfuscation will quietly bump your minimum Python version — that an obfuscated 3.8 script will suddenly need 3.10. It didn't. For every feature that exists on older Pythons, the obfuscated output ran correctly all the way back to that feature's introduction version. Obfuscated f-string code still runs on 3.8; obfuscated match/case code runs on 3.10+; the transformer's own injected wrapper and junk code stayed within the syntax the input already used.

For anyone selling software that has to support a range of Python versions, that's the important result: obfuscate against your real target and the output keeps the same compatibility floor. Async functions, dataclasses, decorators, and complex type hints all survived every transformation layer intact and produced identical results.

Two features failed to obfuscate at all, and it's the same root cause: the engine parses your code with CPython 3.11, so syntax that only exists in 3.12+ can't be parsed.

• PEP 695 type parameters — def first[T](xs: list[T]) -> T: and type Alias = ... (Python 3.12+) raise a SyntaxError in the obfuscator.
• t-strings — t"..." template strings (PEP 750, Python 3.14+) also raise a SyntaxError.

Note the precise scope: this is only about the new syntax itself. Ordinary code that *targets* 3.12 or 3.13 obfuscates and runs fine — every non-syntax-specific fixture passed on 3.12 and 3.13. You only hit the wall if a file actually uses PEP 695 type-parameter syntax or t-strings. The practical workaround today is to write those few declarations in the pre-3.12 equivalent (TypeVar instead of [T]), or keep the handful of files that need the new syntax unobfuscated and lean on obfuscating the rest.

Full pro-mode obfuscation is not small — control-flow flattening and junk injection add substantial bulk. On these tiny single-feature fixtures the expansion looked enormous (100–450×) simply because the fixtures are a few dozen bytes and the injected scaffolding dominates. On real modules the ratio is far lower: in a separate retained test, a 718-byte fixture became a 30,497-byte standalone file — about 42× — and the ratio keeps shrinking as your actual code grows relative to the fixed scaffolding.

Environment: the obfuscator engine on CPython 3.11.5; obfuscated output executed on 3.8.20, 3.9.25, 3.10.20, 3.11.5, 3.12.13, 3.13.14, 3.14.2 (Windows x86-64). Full pro pipeline enabled. Each fixture prints a fixed marker on success, and a run counts as passing only if that marker appears in stdout. Here are two of the fixtures so you can reproduce the method:

def cls(c):
    match c:
        case [a, b]:
            return a + b
        case _:
            return -1
print("RESULT_OK" if cls([2, 3]) == 5 else "bad")

def first[T](xs: list[T]) -> T:
    return xs[0]
print("RESULT_OK" if first([9, 8]) == 9 else "bad")

Obfuscate each with the Python Obfuscator, then run the output on each interpreter with the marker check. If you're selling software, this is exactly the pre-ship test worth automating — see how to protect Python before selling it.