A passphrase isn't a key — it has to be turned into one
AES encryption needs a 256-bit key: a fixed-length block of random-looking bytes. A human passphrase is nothing like that — it's a variable-length string with far less entropy per character than a truly random key would have. Using a passphrase directly as an AES key would be both technically wrong (wrong length, wrong randomness properties) and practically dangerous, since a passphrase's predictability would undermine the cipher's strength. The bridge between the two is a key derivation function: an algorithm that transforms a passphrase into a properly-sized, cryptographically suitable key.
This tool uses PBKDF2 with SHA-256 and 100,000 iterations for that transformation — a well-established, browser-native key derivation function (available directly through the Web Crypto API) that takes your passphrase and a random salt and produces the actual AES key used underneath.
Why 100,000 iterations, and what that number is actually defending against
PBKDF2's iteration count exists specifically to slow down brute-force attacks against weak or guessable passphrases. Each iteration re-applies the hash function to its own output, meaning deriving the key from a candidate passphrase takes measurably longer than a single hash operation — multiply that cost by 100,000, and an attacker trying millions of candidate passphrases against stolen ciphertext faces a proportionally larger computational bill for every single guess. This doesn't make a weak passphrase strong, but it meaningfully raises the cost of attacking one, converting what might be a fast automated guessing attack into a slow, expensive one.
What's actually packed into the base64 output
| Component | Size | Purpose |
|---|---|---|
| Salt | 16 bytes | Randomizes key derivation so identical passphrases never produce identical keys |
| IV (initialization vector) | 12 bytes | Ensures identical plaintext never produces identical ciphertext |
| Ciphertext + auth tag | Variable | The encrypted message plus GCM's built-in tamper-detection tag |
Encrypting and decrypting
Pick the Encrypt tab and type your secret message.
Enter a strong passphrase — it's the only key to your data, so there's no recovery path without it.
Click Encrypt text to get a base64 ciphertext.
Share the ciphertext; the recipient pastes it in the Decrypt tab with the same passphrase to recover the original message.
Why a fresh salt every time matters
A new, random 16-byte salt is generated for every single encryption operation, even when using the exact same passphrase twice in a row. Without this, two people encrypting the identical message with the identical passphrase would produce identical ciphertext — a pattern an attacker could exploit to detect repeated messages or precompute lookup tables against common passphrases. Because the salt travels along with the ciphertext in the base64 output, decryption only ever needs your passphrase; you never have to separately remember or transmit the salt yourself.
Why GCM mode rejects tampered ciphertext instead of silently decrypting garbage
Matching the tool to the sensitivity of what you're protecting
This encryption approach is genuinely strong — AES-GCM 256 is the same algorithm family securing TLS connections and modern disk encryption — but it's worth being honest about where its practical limits sit. For moderate-sensitivity text — notes, personal messages, non-critical credentials — this is a solid, convenient option with everything happening client-side. For genuinely high-value secrets (a cryptocurrency seed phrase, credentials protecting significant financial access), a dedicated password manager or full-disk encryption system typically adds protections this tool doesn't: hardware-backed key storage that keeps derived keys out of ordinary system memory, and stronger, more brute-force-resistant key derivation functions like Argon2 or scrypt rather than PBKDF2.
Common mistakes
Using a short or predictable passphrase — the 100,000 PBKDF2 iterations slow down brute-force attempts, but they don't compensate for an inherently weak or guessable starting passphrase.
Losing the passphrase with no backup — since it's the only key to the data, there's no recovery mechanism if it's forgotten, unlike account-based systems with password reset flows.
Assuming a 'wrong passphrase' error definitively confirms a typo rather than corrupted or truncated ciphertext — both cases produce the identical authentication failure.
Using this for extremely high-stakes secrets where hardware-backed key storage and a stronger KDF like Argon2 would provide meaningfully more protection.
Real use cases
Sharing a sensitive note or credential with someone over a channel you don't fully trust, using a passphrase communicated separately.
Encrypting a personal note before storing the ciphertext somewhere less secure, like a shared document or cloud notes app.
Protecting text content that needs confidentiality but doesn't warrant setting up a dedicated encryption tool or password manager entry.
Verifying that ciphertext hasn't been tampered with, by relying on AES-GCM's built-in authentication rather than a separate integrity check.
Frequently asked questions
Q: What encryption algorithm is used?
A: AES-GCM with a 256-bit key, the same authenticated encryption used by TLS and modern disk encryption. GCM mode adds an authentication tag so tampered ciphertext is rejected.
Q: How is the key derived from my passphrase?
A: PBKDF2 with SHA-256 and 100,000 iterations, using a fresh 16-byte random salt per encryption — which slows brute-force attacks on weak passphrases by orders of magnitude.
Q: What's inside the base64 output?
A: The salt (16 bytes), the IV (12 bytes), and the ciphertext plus its authentication tag. The salt and IV travel with the ciphertext, so decryption only needs the passphrase.
Q: What happens if I use the wrong passphrase?
A: AES-GCM authentication fails, and the tool reports a clear 'wrong passphrase or corrupted input' error. The plaintext is never revealed on a failed attempt.
Q: Is this suitable for storing secrets long-term?
A: Yes, for moderate-sensitivity data. For high-value secrets, a dedicated password manager or full-disk encryption adds hardware-backed key storage and stronger key derivation functions like Argon2 or scrypt.
Q: Is my text or passphrase uploaded?
A: Never. Encryption and decryption happen entirely in your browser via the Web Crypto API — no server is involved.
Encrypt your text now
Try it with Encrypt & Decrypt Text. Need a strong passphrase to use with it? Try the Passphrase Generator or Password Generator. Want to verify how strong an existing passphrase is first? Check the Password Strength Checker.
