What this protects against
Most "hacked" indie games are not really hacked. Someone opens the game folder, finds the dialogue in a plain .json file or the sprites as loose .png files, and copies or edits them. Encrypting those files turns them into unreadable bytes, so they cannot be opened in a text editor, an image viewer or an archive tool. Your game decrypts them in memory as it loads, using the loader code this tool gives you.
What it does not protect against
This is obfuscation, not DRM. Because your game has to decrypt the files to use them, the key has to ship inside your game. A determined person can read the key out of the build and decrypt everything, and a running game can always be dumped from memory. Treat this as a lock that stops the 95% who would otherwise open your files in Notepad, not as a vault. Anything that must be truly secret, like server keys or anti-cheat checks, belongs on a server you control, not in the client.
How the encryption works
Each file is encrypted with AES-256 in CBC mode using the Web Crypto API built into your browser. A fresh random 16-byte IV is generated per file and written to the front of the output, so two copies of the same file look different. A passphrase is turned into a 256-bit key with SHA-256; or you can generate a random key. The same AES-CBC with PKCS7 padding is available in Godot 4 (AESContext), Unity (System.Security.Cryptography.Aes) and the browser, so the one loader pattern works in all three.
Using the loader
Paste the generated class into your project and keep the key exactly as shown. In Godot, call load_encrypted("res://data/items.json.enc") and parse the returned bytes. In Unity, read the .enc file as a byte array and pass it to GskAssets.LoadEncrypted. On the web, fetch the file as an ArrayBuffer and await loadEncrypted. The code strips the padding and gives you back the exact original bytes.
Is anything uploaded?
No. Files are read and encrypted in your browser with Web Crypto, and the key is never sent anywhere. You can run this page offline.