Python String Encryption: 4 Ways to Hide Strings (Tested)

The most-copied "encrypt a string" snippets on the internet are actually just encoding. base64 is the classic. It makes your string look like random noise, which stops a casual reader — but there's no key, so anyone reverses it in one call:

SECRET = "sk-live-9f8a7b6c5d"
encoded = base64.b64encode(SECRET.encode()).decode()
# encoded -> 'c2stbGl2ZS05ZjhhN2I2YzVk'  (this is what sits in your file)

base64.b64decode('c2stbGl2ZS05ZjhhN2I2YzVk').decode()
# -> 'sk-live-9f8a7b6c5d'   ...anyone can do this

XOR with a key is the next step up, and it has the same fatal flaw: the key is right there in the same file. I XORed the secret with 0x5A and reversed it in one line:

stored = bytes(b ^ 0x5A for b in SECRET.encode())
# stored (hex) -> 29317736332c3f77633c623b6d386c396f3e
bytes(b ^ 0x5A for b in stored).decode()
# -> 'sk-live-9f8a7b6c5d'

If you want genuine encryption, use the cryptography library's Fernet (AES-based, authenticated). It's the right tool for encrypting *data* — a config file, a database field, a message. Real example:

from cryptography.fernet import Fernet
key = Fernet.generate_key()            # e.g. b'sAPGEDzvkTstOcip...'
token = Fernet(key).encrypt(SECRET.encode())
# token -> b'gAAAAABqcKvRvzULfXP9Qd8xJBwrBYQ0...'
Fernet(key).decrypt(token).decode()   # -> 'sk-live-9f8a7b6c5d'

This genuinely protects the data — *if* the key is kept separate. And that's the catch for source-hiding: if you're trying to hide a secret that lives inside the script you're shipping, you'd have to ship the key too. An attacker just reads the key and decrypts. Real crypto doesn't solve "a secret baked into distributed code" — it moves the problem to the key.

So which of these removes the secret from your shipped file? I searched the source produced by each method for the plaintext. base64, XOR and Fernet all pass a naive text search (the string is gone), but remember they're reversible. Here's the summary:

That last row is the important one. Recall that compiling to bytecode leaves your strings in `co_consts` in plain text — so base64-in-source still leaves the *encoded* blob and the decode call visible, and a plain string leaves the literal itself. Our AST obfuscator encrypts each literal with a key derived from a watermark and hides the decoder, so the string appears nowhere — not in the source, not in the compiled constants. I checked:

SECRET in obfuscated_source   -> False
'sk-live' anywhere in co_consts -> False
obfuscated file still runs      -> prints 'sk-live'  (decrypted at runtime)

You can do this yourself in seconds with the free Python Obfuscator — turn on Encrypt and it does exactly this to every string literal in your file, in the browser, nothing uploaded.

Here's the part no string-hiding trick escapes: at runtime, the plaintext has to exist. However you encode or encrypt a literal in your code, the program must decode it back to the real value to use it — so anyone who can run your code (or attach a debugger, or print it) can recover it. String hiding raises the effort of a static read of your file; it does not make a baked-in secret safe from someone running your program.

• Encrypting data (files, fields, messages)? Use cryptography / Fernet with a key you store separately.
• Keeping a real secret out of shipped code? Use environment variables or a secrets manager — not any in-code trick.
• Hiding the string *literals* in source you distribute (endpoints, prompts, license markers, watermarks)? Use AST obfuscation — it encrypts every literal and hides the decoder, clearing them from source and co_consts.
• Just avoiding a casual grep / shoulder-surf? base64 is fine — as long as you remember it's reversible in one line.

String encryption is one layer of a bigger picture. For the full stack — renaming, string encryption, control-flow flattening and compilation — see how to protect Python source code.