Skip to main content
Security Module

AST Python Obfuscator

Free online Python obfuscator: rename identifiers, encrypt strings, hide imports and flatten control flow at the AST level, then download standalone Python.

Why use this tool?

Use the AST Obfuscator when you need to distribute proprietary Python software without exposing your core algorithms in immediately readable source. Anyone you send a plain .py file to can inspect its business logic, copy algorithms, or modify licensing checks. Obfuscation raises that effort by making the implementation harder to follow while producing a Python release artifact you can validate and ship.

It is the right tool for commercial CLI tools, trading and automation bots, game scripts and plugins, paid Discord/Telegram bots, and freelance deliverables where you want the client to run the software but not easily follow or reuse its implementation. The result is a standalone Python release artifact that you can validate with your normal test suite before shipping.

Advertisement
Source Code16 lines · 495 B
7-Layer Security:
import math
import hashlib
import random

def summarize(words):
    total = sum(len(w) for w in words)
    longest = max(words, key=len)
    sig = hashlib.md5("".join(words).encode()).hexdigest()
    return total, longest, sig[:8]

random.seed(42)
words = ["python", "obfuscate", "protect", "deploy"]
count, longest, sig = summarize(words)
print("sorted:", sorted(words))
print("total:", count, "longest:", longest)
print("sig:", sig, "| pi:", round(math.pi, 4), "| pick:", random.choice(words))
Secured Output
Loading secure engine…
Next step after obfuscating

Obfuscation hides your code. Licensing controls who runs it.

Add license keys to your obfuscated script with Licers.com — bind each key to a device (HWID), set expiry, and verify with Ed25519-signed responses a fake server can't forge. Free forever, pip install pylicensify and a few lines of Python.

Protect it free →

Tool facts

Supported Python
Python 3.x source
Input limit
Up to 2 MB per submission
Last reviewed
2026-08-24

What it can't do

  • Make code impossible to reverse-engineer — obfuscation raises the effort, it is not encryption.
  • Control who is allowed to run your code — that needs license validation, not obfuscation.
  • Obfuscate compiled binaries, .pyc files, or non-Python source.

About AST Python Obfuscator

The AST Obfuscator is a source-code protection tool designed to transform readable Python into a deliberately unreadable form while preserving its behavior. It exists to solve a structural weakness of the language: Python is distributed as source, and even 'compiled' .pyc bytecode can often be decompiled with free tools. If your intellectual property lives in a .py file, sharing it exposes that implementation. Obfuscation raises the cost of reverse engineering so casual copying becomes less practical.

Under the hood, the tool works at the Abstract Syntax Tree (AST) level rather than with fragile find-and-replace text edits. It parses your script into Python's own tree representation of the code, rewrites that tree, and then regenerates source from it. AST-aware transformation reduces the fragility of text replacement, but generated output should still be run through your normal test suite before release.

In our retained August 14, 2026 Windows test, the local engine behind this tool transformed the same 28-line, 718-byte fixture into a 30,497-byte standalone .py file in 192.8 ms. The output reproduced invoice-total:27.03 under CPython 3.11.5, and a basic byte scan did not find the three selected source markers. This is one reproducible functional check, not proof against reverse engineering; see the tested Python obfuscator comparison for the fixture, commands, limitations, and alternative artifact models.

Several transformations are applied. Identifier renaming replaces your descriptive variable, function, and class names with meaningless hashes, so a reader can no longer follow intent from names like calculate_license_signature. String encryption hides literal values — API endpoints, license messages, prompts, secret markers — behind runtime decryption so they don't appear in plain text when someone greps the file. Control-flow obfuscation and dead-code insertion restructure the logic and pad it with plausible-looking but unreachable branches, which frustrates both human readers and automated decompilers trying to reconstruct your original flow.

Obfuscation is one point on a spectrum of protection, and it helps to know where it sits. Minification mainly reduces source size and is easy to reverse. Shipping .pyc bytecode adds a barrier but can often be decompiled with tools such as uncompyle6 or decompyle3. AST obfuscation keeps the release artifact in pure Python while making its structure harder to understand. Native .pyd/.so compilation with Cython or a compiled application from Nuitka can present a higher barrier because you ship machine code instead of Python source, although native binaries can still be reverse engineered. Commercial protectors such as PyArmor use a different runtime-backed artifact model. Choose based on compatibility, deployment, and threat model rather than treating any option as irreversible protection.

Best practice is to keep a clean, unobfuscated copy of your source in version control and treat the obfuscated file as a build artifact you regenerate on release — never edit the generated output by hand. Run your normal test suite against that artifact before shipping. Obfuscation hides how code works but does not control who may run it, so commercial software may also need license validation designed for its threat model.

A realistic note on limits: obfuscation is a deterrent, not encryption. A determined attacker with enough time can still recover behavior because the interpreter must execute the program. The practical goal is to raise the effort required to copy or modify the implementation. Its effectiveness depends on the code, enabled transformations, attacker, and deployment, so treat it as one layer rather than a security guarantee.

Want to go deeper? Follow the step-by-step walkthrough on how to obfuscate Python code, then read whether Python obfuscation is actually secure to set realistic expectations before you ship.

See a real before-and-after (tested)

Here is an actual run with every layer enabled, not a mock-up. We take a small, readable billing helper, obfuscate it with all layers on, and check the result. Because the tool rewrites Python's own Abstract Syntax Tree and regenerates source, the obfuscated file is ordinary Python you run the same way — python your_file.py.

Before — sample.py · 13 lines, 305 bytes
def price_with_tax(amount, rate):
    tax = amount * rate
    total = amount + tax
    return round(total, 2)


def print_invoice(customer, amount, rate):
    total = price_with_tax(amount, rate)
    print(f"invoice-total:{total} for {customer}")
    return total


print_invoice("Acme Ltd", 100.0, 0.18)
After — obfuscated.py · 67 lines, 24,332 bytes
# the obfuscated file still runs identically:
$ python obfuscated.py
invoice-total:118.0 for Acme Ltd

# the original names and string literals are gone from the file:
$ grep -E "price_with_tax|print_invoice|invoice-total|Acme Ltd" obfuscated.py
# (no matches)

# size grew as the structure was hidden:  305 B -> 24,332 B  (13 -> 67 lines)

Troubleshooting: when an obfuscated script misbehaves

Obfuscation renames identifiers and hides string literals, so the handful of things that can break are almost always code that depends on the original names, or on reading its own source. Each has a simple fix.

A lookup by name fails (getattr, globals(), plugin registries)

If your code fetches a function or attribute by its original text name — getattr(obj, "price_with_tax"), globals()["run"], or a plugin registry keyed on function names — that name no longer exists after renaming. Reference the object directly instead of by string, or keep those specific entry points out of the renamed set.

A framework can't find your handler or task

Tools that discover code by its exact name — web-route handlers, Celery task names, or pytest's test_* discovery — depend on names that obfuscation changes. Obfuscate the internal logic and leave the public entry-point names intact.

Logs and tracebacks show scrambled names

Error messages, __name__, and any logging that prints function or class names will show the hashed names. That's expected, not a failure — keep the clean source in version control so you can still map a traceback back to the original code.

The output is much larger or slower on big files

Control-flow changes and inserted dead code add the most size and runtime overhead, and they compound on large files. If startup time or file size matters, enable fewer layers and benchmark the generated artifact on a representative workload.

It ran before obfuscating but not after — test the artifact

The transformations are applied to a copy, so run your normal test suite against the generated file before shipping. Never hand-edit the obfuscated output; regenerate it from source on each release.

Frequently Asked Questions

No. Obfuscation can increase the time and skill required to understand a script, but it cannot make executable code impossible to reverse engineer. Enabling more transformations adds obstacles; for a higher barrier, evaluate native compilation with Cython or Nuitka and test the resulting deployment against your compatibility requirements.