Python Minification vs Obfuscation: What's the Difference?

A small licensing helper — it has comments and a docstring for the minifier to strip, and a hard-coded secret to see whether either transform hides it:

"""Licensing helper for the demo app."""
import hashlib

# The product's license secret — must never be exposed to users.
LICENSE_SALT = "salt-9f83-demo"

def make_key(user_id: int, plan: str) -> str:
    """Return a deterministic license key for a user and plan."""
    raw = f"{user_id}:{plan}:{LICENSE_SALT}"
    return hashlib.sha256(raw.encode()).hexdigest()[:16]

def verify(user_id, plan, key):
    # Recompute and compare.
    return make_key(user_id, plan) == key

Minification strips everything the interpreter doesn't need — comments, docstrings, blank lines, and extra whitespace — and collapses statements onto shared lines. Here's the file minified (no renaming):

import hashlib
LICENSE_SALT='salt-9f83-demo'
def make_key(user_id,plan):raw=f"{user_id}:{plan}:{LICENSE_SALT}";return hashlib.sha256(raw.encode()).hexdigest()[:16]
def verify(user_id,plan,key):return make_key(user_id,plan)==key

It dropped from 584 to 316 bytes — 46% smaller — and still runs identically. But read it: the license salt 'salt-9f83-demo' is right there, the function names are intact, and the logic is trivially followable. Minification made the file *denser*, not *hidden*.

This is where the confusion starts. Minifiers *can* also shorten identifiers, which looks like obfuscation. I re-ran it with global and local renaming on:

C='pro'
import hashlib as D
E='salt-9f83-demo'
def A(user_id,plan):A=f"{user_id}:{plan}:{E}";return D.sha256(A.encode()).hexdigest()[:16]
def F(user_id,plan,key):return A(user_id,plan)==key

Smaller still (258 bytes, 56% off), and now make_key is A, LICENSE_SALT is E. But look at what renaming can't touch: E='salt-9f83-demo' — the secret is still sitting there in plaintext. Renaming hides the *names* you chose, which were never the sensitive part. Your string literals — keys, tokens, URLs — pass straight through.

Obfuscation is aimed at the opposite goal — making the code hard to understand — so it does the things minification won't: it encrypts the string literals and restructures the program, on top of renaming. I ran the same file through our Python Obfuscator:

$ obfuscate app.py --pro
# 584 bytes -> 33,259 bytes  (+5,595%)
# secret 'salt-9f83-demo' : NOT found in output
# still runs: valid: True

Note the direction of the size change: the file got ~57× bigger, because encryption and the decode machinery add real bytes. The trade is the whole point — a text search for the salt now finds nothing, and the output is unreadable, but it still runs and produces the same key. Obfuscation buys secrecy at the cost of size; minification buys size at the cost of nothing (because it protects nothing).

Pick by goal, not by which word you heard first:

• You want a smaller, faster-loading file (shipping code to a browser, trimming a package, a size-limited environment) → minify. Try our free Python Minifier. Keep the readable source in version control; ship the minified copy.
• You want to hide logic or make reverse-engineering costly → obfuscate. Use the Python Obfuscator, which renames at the AST level *and* encrypts strings — the part minification skips.
• You want to hide a real secret (an API key, a license authority) → do neither in isolation. As the tests show, a hard-coded secret survives minification and is only *scrambled* by obfuscation (a running program still reconstructs it). Keep it off the client entirely — see how to protect API keys in Python.

And if you're weighing obfuscation seriously, read is Python obfuscation secure? and how to protect Python source code first — obfuscation raises the cost of reversing your code, it doesn't make it impossible.