Compressing Python Bytecode: zlib vs zstd (Tested)

A .pyc-style marshal blob is raw bytecode plus all your string and numeric constants — it isn't small, and to put it in a self-contained loader you base64-encode it, which adds ~33%. Compression claws that back: bytecode has a lot of structural repetition, so it compresses well. You get a smaller artifact to ship, and the blob stops being trivially greppable for string constants (a minor, *incidental* obfuscation — not real protection).

Two standard-library options can do the compressing, and the loader just reverses it at import time:

• `zlib` — in every CPython since forever. Maximum portability; the loader runs anywhere your target Python does.
• `compression.zstd` — new in Python 3.14 (PEP 784). Zstandard's algorithm, wrapped in a stdlib module — but *only* stdlib on 3.14+.

I compiled and marshaled six real stdlib modules of increasing size, then measured the base64-encoded size of each compressed payload — because that's what actually ships in the loader. zstd was measured at both its default level and level 19 (near-max):

import marshal, zlib, base64, importlib.util
from compression import zstd

def measure(module):
    src = open(importlib.util.find_spec(module).origin, encoding="utf-8").read()
    raw = marshal.dumps(compile(src, module, "exec"))
    b64 = lambda data: len(base64.b64encode(data))
    return {
        "raw":    len(raw),
        "zlib":   b64(zlib.compress(raw, 9)),
        "zstd":   b64(zstd.compress(raw)),          # default level (~3)
        "zstd19": b64(zstd.compress(raw, level=19)),
    }

print(measure("argparse"))
# {'raw': 113557, 'zlib': 61868, 'zstd': 63740, 'zstd19': 57288}

Sizes are bytes. raw marshal is the uncompressed bytecode; the three compression columns are the base64 sizes as they'd appear in a loader. The last column is level-19 zstd versus max zlib — the apples-to-apples comparison:

Two things jump out. First, zstd only wins at a high level. Its *default* level (around 3) is consistently *worse* than max zlib — look at argparse: default zstd is 63,740 bytes versus zlib's 61,868. If you call zstd.compress(raw) without a level, you've made the file bigger, not smaller.

Second, at level 19 zstd wins, and the margin grows with size — from a barely-there 2.7% on the 2 KB json.scanner to 9.3% on the 135 KB typing. That's the nature of the algorithm: zstd's larger window and better entropy coding need volume to pay off, so on a tiny script it's a wash, and on a big module it's a real few-kilobyte saving.

Here's what decides it for most people. A compressed loader has to *decompress* at runtime, so whatever module you used must exist on the machine that runs it. zlib always does. compression.zstd is standard-library only on Python 3.14+ — on 3.13 and earlier the import fails outright:

# Python 3.14+
from compression import zstd     # works

# Python 3.13 and earlier
from compression import zstd
# ModuleNotFoundError: No module named 'compression'

This dovetails with marshal's own rule: marshaled bytecode is version-locked — a blob built for 3.14 only loads on 3.14 anyway. So if you're targeting 3.14, a zstd loader is fully consistent (both halves need 3.14+). If you need your loader to run on 3.10–3.13, you're on zlib regardless — there's no stdlib zstd there to decompress it.

import marshal, base64
from compression import zstd
exec(marshal.loads(zstd.decompress(base64.b64decode("<blob>"))))

In our free Marshal Encryptor you can pick None, zlib, or zstd and watch the size stats update — selecting zstd targets Python 3.14 automatically, since that's where compression.zstd lives. Want to see what's inside the blob it produces? Disassemble a snippet in the bytecode disassembler to confirm marshaled bytecode hides nothing.