Text Encryptor / Decryptor

What this tool does, precisely

This tool takes a piece of text and a password and turns the text into an unreadable block of base64 (encryption), or takes that block plus the original password and recovers the text (decryption). The security is real, not cosmetic: it uses AES-GCM with a 256-bit key, the same authenticated cipher that protects HTTPS traffic and disk encryption. Everything happens in your browser through the WebCrypto API — your text and password never leave your device, and there is no server to log them. You can disconnect from the internet and it still works.

How a password becomes a key

A password is not an encryption key. Passwords are short, guessable, and have low entropy; AES needs a uniformly random 256-bit key. The bridge between them is a key derivation function. This tool uses PBKDF2 with SHA-256 and 100,000 iterations over a random 16-byte salt. In plain terms:

• A fresh random salt is generated for every encryption, so the same password produces a different key each time.
• PBKDF2 runs the hashing 100,000 times. That deliberate slowness barely affects you (a fraction of a second) but multiplies the cost of an attacker guessing passwords by 100,000.
• The result is a 256-bit AES key that only your password and that salt can reproduce.

AES-GCM then encrypts using a random 12-byte initialization vector (IV), and crucially it produces an authentication tag. That tag is what makes GCM "authenticated": if even one byte of the ciphertext or the password is wrong, decryption fails outright instead of returning garbage. You get a clear "decryption failed" message rather than silent corruption.

What the ciphertext actually contains

The base64 string the tool outputs is a self-contained bundle. The first 16 bytes are the salt, the next 12 are the IV, and the rest is the AES-GCM ciphertext (including its authentication tag). Because the salt and IV travel with the ciphertext, the recipient needs only two things to decrypt: the base64 string and the password. There is no separate key file to manage. Note that salt and IV are not secret — they are meant to be public — so bundling them in is standard, safe practice. The only secret is the password.

A worked example

Type Meet me at 6pm as the plaintext and river-otter-92 as the password, then press Encrypt. The tool derives the key, encrypts, and returns something like k3Jd…== — a chunk of base64 that looks like noise. Send that block to a colleague through any channel and tell them the password separately (ideally by a different route). They paste the block into Decrypt mode, enter river-otter-92, and get Meet me at 6pm back. If they type river-otter-93 by mistake, decryption fails cleanly: GCM's authentication tag refuses to produce wrong-but-plausible output.

Genuine use cases

• Sending a secret over an insecure channel. Encrypt a note before pasting it into chat, email, or a ticket, and share the password out of band.
• Storing sensitive snippets. Keep recovery codes, a private address, or API notes as ciphertext in a document so a casual reader of that file sees only noise.
• Personal "envelopes." Encrypt something to your future self with a password you will remember.

Common mistakes and limits

• Losing the password. There is no recovery and no backdoor. If you forget the password, the ciphertext is unrecoverable by design — that is the whole point. For anything important, store the password in a password manager.
• Sending the password alongside the ciphertext. Putting both in the same email defeats the encryption. Share them through separate channels.
• Using a weak password. AES-256 is unbreakable in practice, so attackers go after the password instead. A short or common password can be guessed despite the 100,000 PBKDF2 iterations. Use a long, unique passphrase.
• Editing the ciphertext. The base64 block is exact. Adding a stray space, truncating it, or letting an email client wrap lines can corrupt the salt or IV and make decryption fail. Copy it whole.
• Expecting it to hide that a message exists. Encryption hides the content, not the fact that you sent something. It is confidentiality, not invisibility.

Why in-browser encryption is trustworthy here

Web-based crypto tools are only as private as their plumbing. Because this one calls the browser's native WebCrypto API and performs every step — key derivation, encryption, decryption — on your own machine, your plaintext and password are never transmitted, never logged, and never stored on a server. Turn off your connection and encrypt a message: it works, which is the simplest proof that nothing is being sent.