How AES encryption works
AES (Advanced Encryption Standard) is the symmetric block cipher standardised by NIST in FIPS 197 and used everywhere from TLS and disk encryption to messaging apps. Symmetric means one shared secret both encrypts and decrypts — there's no public/private key pair here. It works on 128-bit blocks with a key of 128, 192, or 256 bits; more bits means a larger keyspace, not stronger math.
Three pieces turn a human passphrase into safe ciphertext. A key derivation function (PBKDF2 here) stretches your passphrase with a random salt and many iterations into a proper key, making brute-force expensive. A cipher mode (CBC, CTR, …) decides how blocks chain together, and an initialization vector randomises the start so the same input never yields the same output twice. Get any of these wrong on the way back in and decryption fails by design.
Everything runs 100% in your browser via CryptoJS — your plaintext, passphrase, salt, and IV never touch a server, so it's safe to work with real secrets.
Encryption vs. hashing
Two-way and reversible — with the key you get the original data back.
One-way and irreversible — a fixed fingerprint you can't turn back into the input.
Where developers use it
Encrypting a config value
Protect an API key or connection string before committing it, then decrypt at deploy time with the shared passphrase.
Sharing a secret safely
Encrypt a note for a teammate and send the ciphertext over an untrusted channel, passing the key separately.
Testing an integration
Reproduce the exact mode, padding, and KDF another system uses to confirm your ciphertext round-trips.
Frequently asked questions
AES is symmetric — the same passphrase and parameters must be used both ways. Decryption only succeeds if the mode, padding, key size, KDF (and its iterations/hash), and the salt and IV all match what was used to encrypt. A single mismatch yields garbage or a padding error — that's expected, not a bug.
A passphrase is human-typed text; AES actually needs a fixed-length binary key. A KDF like PBKDF2 stretches your passphrase (with a salt and many iterations) into that key, which slows down brute-force guessing. The Direct option skips this and uses your input as raw key bytes — only use it when you already have a proper key.
Both are considered secure. AES-256 has a larger key space (2^256 vs 2^128), giving a wider safety margin — including against future attacks — at a small performance cost. For most workloads AES-256 is the conservative default; AES-128 remains perfectly strong for general use.
The initialization vector randomises the first block so that encrypting the same plaintext twice produces different ciphertext. It doesn't need to be secret, but it must be unique per message and stored alongside the ciphertext so you can decrypt. A fresh random IV is generated for you each time.
For general use, CBC with PKCS7 padding is a safe, widely-compatible default. Avoid ECB — it encrypts each block independently, so identical plaintext blocks produce identical ciphertext and patterns leak. Authenticated modes like GCM are even better when available, since they also detect tampering.
Generally no. With a KDF the salt determines the derived key, and the IV seeds the first block, so losing either prevents a correct round-trip. Always store the salt and IV alongside the ciphertext — they aren't secret, but they are required to decrypt.
A padding oracle attack abuses a server that reveals whether decryption padding was valid, leaking plaintext over many requests. This tool decrypts entirely locally in your browser with no network oracle to probe, so the classic attack doesn't apply here.
No. All key derivation and AES operations run in your browser via CryptoJS. Your plaintext, passphrase, and keys never leave the page — safe for real secrets.