AES Encryption Online — Encrypt Text With a Password
Real AES-256-GCM in your browser: encrypt a message, share it, decrypt with the password.
🔒 Runs in your browser — files never uploaded ⚡ No signup 💯 Free
There is no recovery: lose the password and the message is gone for good. Pick a strong one — the encryption is only as strong as it.
Encrypt any text with a password using AES-256-GCM — the browser's native Web Crypto, not a JavaScript imitation. The result is a single text block you can email, message or store anywhere; whoever has the password pastes it into the Decrypt tab and gets the original back.
Keys are derived with PBKDF2 at 310,000 iterations, every message gets a fresh random salt and IV, and the GCM mode authenticates as well as encrypts — a wrong password fails cleanly instead of producing garbage. Nothing ever leaves your browser.
How to use AES Encrypt / Decrypt
- Type or paste the text and choose a password — a strong one; it carries all the security.
- Click Encrypt and copy the resulting block. It's safe to send over any channel.
- Share the password separately — different channel than the message, always.
- To decrypt: paste the block into the Decrypt tab, enter the password.
What this is good for — and not
Good for: sending something sensitive over a channel you don't fully trust (email, chat), stashing a note in a file or cloud drive, sharing credentials where a password manager's sharing feature isn't available. The pattern that makes it work: the message and the password travel by different routes. Encrypted blob by email, password by phone — an attacker needs both.
Not a replacement for: disk encryption, password managers, or end-to-end messaging apps, which handle keys for you and protect metadata too. This is a hand tool, not infrastructure.
Why GCM, why 310,000 iterations
AES-GCM is authenticated encryption: the ciphertext carries a tag proving it wasn't modified and that the key is right. Decrypting with a wrong password fails with an error rather than emitting plausible-looking noise — which is what older CBC-based tools do, and it matters. PBKDF2-SHA256 at 310,000 iterations (the OWASP figure) makes each password guess deliberately expensive: the half-second the button takes is the security working.
There is no recovery
No account, no reset, no backdoor: the password is the only key. This is a feature — it's what "nobody else can read it" means — but it cuts both ways. Lose the password, lose the message. For anything long-lived, store the password in a password manager.
Can I decrypt this elsewhere?
The format is standard building blocks (PBKDF2-SHA256 → AES-256-GCM, salt and IV prefixed) but the envelope is this tool's own — practical portability is "decrypt it on this page". The page works offline once loaded, and there is nothing server-side to disappear: the crypto is your browser's.
Frequently asked questions
How secure is this really?
The primitives are the strong ones — AES-256-GCM and PBKDF2-SHA256 at 310,000 iterations, straight from your browser's native Web Crypto — and each message gets a fresh random salt and IV. The honest caveat: the weak link is the password. Encryption with "hunter2" is theatre; with 16 random characters it's genuinely strong.
I forgot the password — can the text be recovered?
No. There is no account, no reset and no backdoor; the password is the only key. That's the security property working as designed, and it cuts both ways — store the password in a password manager for anything you'll need later.
Why does decrypting with the wrong password show an error instead of gibberish?
GCM is authenticated encryption: the ciphertext carries a tag that only verifies with the right key and an unmodified message. Wrong password → tag fails → clean error. Older CBC tools emit random bytes on a wrong key, which is both confusing and a subtle security weakness.
Is my text or password sent to your server?
No — key derivation, encryption and decryption all run in your browser. The page works offline once loaded. The one thing to keep in mind is that the encrypted result is only as private as wherever you paste it.
How should I share the password with the recipient?
By a different channel than the message. Encrypted block by email, password by phone call or in person — an interceptor then needs to compromise both. Sending both in the same email defeats the whole exercise.