Text Encrypter

Encrypts text with AES-256-GCM under a key derived from your passphrase with PBKDF2-HMAC-SHA256 at 600,000 iterations, and packs the result into one compact base64url string you can paste anywhere. The string carries its own format version, iteration count, 16 byte salt, and 12 byte nonce, so decrypting it needs nothing but the passphrase. GCM authenticates the message as well as hiding it, so an altered message fails to decrypt instead of quietly producing garbage.

Type the text you want to protect into the box, then put the passphrase in the Password option, which is masked and never written to the address bar. Copy the armored message and send it however you like, then give the recipient the passphrase through a different channel. To read one, paste the armored message into the box, type the passphrase into the same option, and switch Mode to Decrypt. The older form still works too: leave the option empty and put the passphrase below a line of three dashes.

The other encrypt-a-message sites either post your text and passphrase to a server, or store the message for you behind a link, which turns a private note into somebody else's database row. Here the derivation and the encryption run in the browser's own cryptography engine: your files and inputs never leave your device, nothing is stored, and there is no server endpoint. The parameters are stated plainly instead of hidden behind the word AES.

How strong is this, really?

The cipher is not the weak part: AES-256-GCM with a random 96 bit nonce is what TLS uses. The strength you actually get is the strength of your passphrase, stretched by 600,000 PBKDF2 iterations. That stretching makes each guess roughly a quarter of a second of work on a laptop, which is fatal to a five word dictionary passphrase given a real GPU rig and merely painful for a long random one. Use a passphrase you would be comfortable using on a password manager vault, not one you would use on a forum.

What is in the armored string?

One version byte, the PBKDF2 iteration count as four bytes, the 16 byte salt, the 12 byte nonce, and then the ciphertext with its 16 byte authentication tag, all base64url encoded with the padding stripped. The header is also fed to AES-GCM as additional authenticated data, so changing the stated iteration count breaks decryption rather than tricking the reader into deriving a weaker key. None of that is secret; only the passphrase is.

It says the password did not decrypt the message. What now?

AES-GCM cannot tell a wrong passphrase from an altered message, because both fail the same authentication check, so the tool cannot tell you which happened. Check the passphrase first, including capitalization and a trailing space that a chat app may have added. If the passphrase is definitely right, the message itself changed: recopy it in full, since a truncated paste or an email client that inserted a line break will both do this.

Does the passphrase end up in the URL when I share a link?

No. Option values are normally stored in the page URL so a link can carry your settings, but the Password option is flagged as a secret: it is masked on screen, it is never written to the address bar, and a link that tries to pre-fill it is ignored. The message box is kept out of the URL as well, because it still accepts the older form where the passphrase is typed below a line of three or more dashes.

Can I recover a message if I forget the passphrase?

No, and that is the point. There is no account, no stored copy, and no reset: the passphrase is the only thing that derives the key, and it is never written anywhere. If losing access would be a disaster, keep the passphrase in a password manager before you send the message.