Text Encryption Tool
Encrypt or decrypt text with a passphrase using real AES-256-GCM encryption, computed entirely in your browser.
About the Text Encryption Tool
Encryption is handled by the browser's native AES-256-GCM implementation, with your passphrase run through PBKDF2 at 100,000 iterations (SHA-256) and a fresh random salt and IV generated each time you encrypt, all without the text leaving the page. It's a solid convenience tool for everyday use, but for genuinely sensitive data you'd still want dedicated, audited security software instead.
Why your passphrase isn't used directly as the encryption key
AES-256 needs a 256-bit key with genuinely uniform randomness across all 256 bits, but a human-chosen passphrase, even a decent one, has far less real entropy than that and often follows predictable patterns. PBKDF2 (Password-Based Key Derivation Function 2) bridges that gap, it takes your passphrase and deliberately, repeatedly hashes it to stretch it into a properly-sized key, while also intentionally slowing the whole process down. That deliberate slowness is the entire point: it makes brute-force guessing dramatically more expensive for an attacker without meaningfully inconveniencing you, since you're only running it once per encryption or decryption.
Why specifically 100,000 iterations
Each PBKDF2 iteration means running SHA-256 once more on the accumulated result, and 100,000 of them takes a legitimate user only milliseconds on a normal device, an imperceptible one-time cost per operation. But an attacker trying to guess your passphrase has to pay that identical 100,000-iteration cost for every single guess they make, turning what might otherwise be millions of cheap guesses per second into a dramatically slower process. This "work factor" concept, deliberately expensive-but-tolerable computation, is the whole security value PBKDF2 adds on top of a weak or guessable passphrase.
Why a fresh salt is generated every single time you encrypt
The salt, 16 random bytes generated fresh for each encryption, gets mixed into the key derivation so that even the exact same passphrase produces a completely different derived key every time. Without this, an attacker could precompute a table of derived keys for common passphrases once and reuse it against any ciphertext they intercept, or notice that two messages encrypted with the same passphrase share telltale similarities. With a fresh salt every time, that precomputation attack becomes worthless, and encrypting identical text twice with the identical passphrase produces two completely unrelated-looking outputs.
Why the IV also has to be unique, even more strictly than the salt
AES-GCM has a hard security requirement: the same key and IV (initialization vector) combination must never be used to encrypt two different messages, doing so can catastrophically undermine the cipher's confidentiality guarantees. Since a fresh key is derived from a fresh salt on every encryption here anyway, generating a fresh random 12-byte IV alongside it (the standard size for GCM) ensures this critical constraint holds even in the unlikely event of a salt collision, defense in depth on a rule that genuinely cannot be violated safely.
Why salt, IV, and ciphertext are all bundled into one output string
Neither the salt nor the IV is secret, both need to be available again at decryption time to re-derive the identical key and re-run the cipher with the same parameters. Rather than requiring you to separately track and store three different values, this tool concatenates salt, then IV, then ciphertext into one byte sequence and base64-encodes the whole thing as a single portable string. That's why the encrypted result is just one block of text you can copy, paste, and store anywhere, decryption only needs that one string plus your passphrase, nothing else.
Why a wrong passphrase produces a clean error instead of garbled output
GCM is an authenticated encryption mode, meaning it bakes in an integrity check alongside the encryption itself. If you attempt to decrypt with the wrong passphrase, or if the ciphertext has been altered or corrupted in any way, that built-in authentication check fails and the browser's crypto engine throws an error rather than returning silently-corrupted plaintext. Since a wrong passphrase and genuinely corrupted data both trigger that exact same authentication failure with no way to distinguish between them, this tool's error message honestly reflects that ambiguity, "Wrong passphrase or corrupted data" rather than falsely claiming to know which one actually happened.
Frequently Asked Questions
Why isn't my passphrase used directly as the AES encryption key?
AES-256 needs a properly-sized 256-bit key with uniform randomness, which a human passphrase doesn't naturally have. PBKDF2 stretches your passphrase into a suitable key while deliberately slowing the process down, making brute-force guessing dramatically more expensive for an attacker.
Why does the tool use exactly 100,000 PBKDF2 iterations?
Each iteration adds negligible cost for a legitimate one-time encryption or decryption, but forces an attacker to pay that same cost on every single guess when trying to brute-force your passphrase, turning millions of cheap guesses per second into a dramatically slower process.
Why does encrypting the same text with the same passphrase produce different results each time?
A fresh random salt is generated for every encryption, which changes the derived key even when the passphrase is identical. This prevents precomputed attacks against common passphrases and means encrypting the same message twice produces two unrelated-looking outputs.
Why does the tool also generate a fresh IV every time?
AES-GCM has a strict requirement that the same key and IV combination must never encrypt two different messages, or the cipher's security guarantees can be undermined. Generating a fresh IV alongside the fresh salt ensures this requirement is respected on every encryption.
Why is everything bundled into one long base64 string instead of separate values?
The salt and IV aren't secret, but both are needed again at decryption to re-derive the identical key and cipher parameters. Bundling salt, IV, and ciphertext into one string means you only need to save and share a single block of text plus your passphrase to decrypt later.
Why does a wrong passphrase show a generic error instead of garbled text?
AES-GCM includes a built-in authentication check, so a wrong passphrase or corrupted ciphertext both trigger the same verification failure rather than producing readable-but-wrong output. Since the two causes are indistinguishable, the error message honestly reflects that ambiguity.