Online AES-GCM encryption tool: PBKDF2 key derivation 256-bit. Processed locally in browser, ciphertext and password never sent.
TL;DR: Free online AES-GCM encryption and decryption tool with PBKDF2 256-bit key derivation. Processed locally in your browser. Ciphertext and password never sent to any server.
For local tools, open DevTools → Network and search your input — it should not appear in requests.
Usage Guide
AES is today's dominant symmetric cipher: encryption and decryption share a key derived from one password, ideal for text you need to read but others must not — keys in configs, private notes, sensitive strings in transit. This tool runs on Web Crypto locally; neither plaintext nor password ever leaves the browser.
1. Encrypt and decrypt
Ciphertext is Base64 and can safely go into JSON, email or config files. A wrong password yields an error rather than garbage — AES rejects wrong keys instead of producing "almost right" output.
- Encrypt: paste plaintext, enter a password (8+ chars, mixed case/digits/symbols), click Encrypt, get Base64 ciphertext.
- Decrypt: paste the ciphertext, enter the same password, click Decrypt.
- The eye icon reveals the password for confirmation — the most common decrypt failure is a single mistyped character.
2. The password is everything: no recovery
Symmetric encryption has no "forgot password" flow — lose the password, lose the data forever. That is also where the security comes from: whoever holds the ciphertext without the password reads nothing. Sending the password and ciphertext through the same channel (messaging app, both in plaintext) defeats the purpose — key and ciphertext should travel separately.
3. Three reasons ciphertext will not decrypt elsewhere
- Output encoding mismatch: this tool emits Base64 while some tools default to hex — confirm encoding first.
- Mode and padding differences: CBC vs GCM and PKCS#7 combinations are mutually incompatible; agree on one mode when working across tools.
- Key derivation mismatch: deriving an AES key from a password has multiple algorithms; same password with different derivation equals a different key. For strict scenarios, use a raw key rather than a password.
4. Why IV/nonce reuse is catastrophic
AES-GCM security assumes the IV is never repeated under the same key. At 96 bits, random-IV collision odds are negligible at small scale, but two consequences are underrated. First: with the same key and IV encrypting two plaintexts, the XOR of the ciphertexts equals the XOR of the plaintexts — an attacker performs known-plaintext inference without the key. Second: in GCM, IV reuse also leaks the authentication subkey, enabling tag forgery. Engineering conclusions: generate IVs from a CSPRNG or manage them as strict counters, never timestamps or reused seeds; and store the IV alongside the ciphertext (it needs no secrecy).
5. A password is not a key
- Human passwords are low-entropy and must be stretched through a KDF (PBKDF2/Argon2) — using hash(password) directly as the key is a classic error.
- PBKDF2 iterations are adjustable: presets around 100k / 310k / 600k trade speed for cost, or set a custom value. Decrypt with the same iteration count used at encrypt time — v2 ciphertext embeds the count; legacy v1 uses the historical default.
- Do not truncate the GCM tag: 128 bits is the default and the recommendation; shorter tags directly weaken forgery resistance.
6. Ciphertext format on this page
AES-256-GCM with PBKDF2-SHA-256 key derivation. Base64 ciphertext: v2 carries a magic header and iteration count; v1 still decrypts. A fresh IV is stored with each message. Other tools with different modes or KDFs will not interoperate — align conventions first.
FAQ
AES-256-GCM, with the key derived from your password via PBKDF2-SHA-256. Every encryption generates a fresh random IV that is stored alongside the ciphertext. Output is Base64: v2 carries a magic header and the iteration count so parameters can be restored across sessions, and legacy v1 ciphertext still decrypts.
No. Symmetric encryption has no "forgot password" flow — the password is the key, and losing it makes the ciphertext permanently unreadable. That is also where the security comes from. Send the password and ciphertext through separate channels: messaging the password in plaintext right before the ciphertext defeats the whole exercise.
Three common reasons: output encoding (this page emits Base64 while some tools default to hex); mode and padding combinations (GCM vs CBC and friends); and key-derivation parameters — the same password with a different PBKDF2 iteration count yields a different key. Align both sides' settings before interoperating.
No. GCM is an authenticated mode, so a wrong password raises an explicit error instead of garbage — it essentially never "happens to decrypt". The most common decrypt failure is one character too many or too few in the password; use the eye icon next to the input to verify it in plaintext.
Go with GCM: it provides confidentiality and integrity in one, detecting tampered ciphertext, while CBC only encrypts. In either mode, never reuse an IV under the same key — reuse in GCM leaks both plaintext relationships and the authentication key, which is worse than most people assume.
Never. Encryption and decryption are done locally by the browser's Web Crypto — plaintext, password, and ciphertext all stay off the network, and the page has no accounts.
Related Tools
Related Articles
Online AES Encryption Tool: Symmetric Encryption Guide
Learn AES symmetric encryption fundamentals. Understand AES-GCM mode, PBKDF2 key derivation, iteration count selection, and how to encrypt and decrypt data using online tools.
AES Encryption in the Browser: A Practical Guide to Web Crypto API
Learn AES encryption in JavaScript using the Web Crypto API. Complete AES-256-GCM encrypt/decrypt example with PBKDF2 key derivation, all running client-side.
Online RSA Encryption/Decryption: Asymmetric Crypto and Digital Signatures
Learn RSA asymmetric encryption algorithm principles and applications. Understand public/private key encryption, digital signatures, key pair generation, and use in HTTPS and API authentication.