Encrypt Text
Encrypt a message with AES-256-GCM and a passphrase, using your browser’s own crypto engine.
Processed on your device — no upload
Type a message and a passphrase. The encrypted result appears here, produced by your own browser.
AES-256-GCM with the key derived from your passphrase by PBKDF2 at 250,000 iterations. A fresh random salt and nonce are generated each time, so encrypting the same message twice produces different output — which is correct, and means you cannot tell from the ciphertext that two messages are the same.
There is no recovery. Lose the passphrase and the message is gone; nobody can reset it, because nobody else ever had it.
How to encrypt text
- Type the message and a passphrase.
- Encrypt, and send the result however you like.
- The recipient pastes it back here with the same passphrase.
How it works
The passphrase is turned into a 256-bit key by PBKDF2 with a random salt and 250,000 iterations, and the message is then encrypted with AES-256-GCM using a random nonce. All of it comes from the Web Crypto API — the browser's own implementation, the same code that protects HTTPS.
The iteration count is the part doing the work. A passphrase alone is far too short to be a key, so PBKDF2 stretches it — and making each derivation take a measurable fraction of a second makes an offline guessing attack 250,000 times more expensive. That is the difference between a weak passphrase being broken in an hour and in a decade.
GCM authenticates as well as encrypts. If a single character of the ciphertext is altered, decryption fails rather than producing plausible wrong text. That is why a failure cannot tell you whether the passphrase was wrong or the message was tampered with — both look identical, deliberately.
The salt and nonce are stored alongside the ciphertext, so decryption needs nothing but the passphrase. A fresh pair is generated every time, which is why encrypting the same message twice gives different output — and why an observer cannot tell that two messages are the same.
A worked example
You need to send a colleague a database password, and the only channel available is company chat, which is logged and searchable.
Encrypt the password here with a passphrase, and paste the encrypted block into chat. Give them the passphrase by a different route — a phone call, in person, a different app. Sending both through the same channel defeats the exercise entirely.
Encrypt the same message twice and compare the two results. They are completely different, because each uses a fresh random salt and nonce. Both decrypt to the same text. If a tool gives you identical output for identical input, it is reusing a nonce, and that is a serious weakness rather than a convenience.
Now change one character in the encrypted block and try to decrypt it. It fails cleanly rather than producing garbage that might be mistaken for the message. That is authentication working.
The honest limits. This protects a message in transit through an untrusted channel. It is not a messaging system: there is no forward secrecy, no identity verification, and no protection if either end's device is compromised. For ongoing confidential conversation use a purpose-built encrypted messenger. For a one-off secret through a channel you do not trust, this is exactly the right size of tool.
The passphrase is the whole security of the scheme — generate a strong one rather than choosing it.
Questions
Is my message uploaded?
No. Encryption and decryption run in your browser using the Web Crypto API. A site that encrypted your message on its server would have seen the plaintext.
How strong is it?
AES-256-GCM is the current standard and is not the weak link. Your passphrase is. The encryption is exactly as strong as the phrase protecting it.
What if I lose the passphrase?
The message is unrecoverable. There is no reset and no back door, because nobody else ever had the key.
Why is the output different every time?
A fresh random salt and nonce are used for each encryption. This is correct behaviour — identical output for identical input would leak information.
Why does it not say whether the passphrase or the message was wrong?
Because it cannot tell. GCM verifies the whole message, and a wrong key and a modified message fail identically. Distinguishing them would itself be a weakness.
Can I use this instead of an encrypted messenger?
For a one-off secret through an untrusted channel, yes. For ongoing conversation, no — there is no forward secrecy and no identity verification.
How should I share the passphrase?
By a different channel from the message. Sending both through the same chat gives an attacker everything in one place.
What is PBKDF2 for?
It converts a passphrase into a key, slowly and with a salt, so guessing attacks are expensive. 250,000 iterations makes each guess roughly a quarter of a million times more costly.