How this text encryption works
The tool turns a message and a password into one block of letters and digits that you can paste into an email, a chat or a note. Only someone with the same password can turn it back. Everything happens in your browser through the Web Crypto API that the W3C specifies, so the message and the password never travel over the network.
- A key from the password. A password is too short and too predictable to be a key, so the tool stretches it with PBKDF2-HMAC-SHA-256 and a fresh random 16-byte salt. It runs 600,000 rounds, the value the OWASP Password Storage Cheat Sheet recommends for PBKDF2-HMAC-SHA256. The result is a 256-bit AES key.
- Encryption with AES-GCM. The text is encoded as UTF-8, so emoji and every script survive, and encrypted with AES-256 in Galois/Counter Mode with a fresh random 12-byte IV. NIST SP 800-38D recommends 96-bit IVs and requires that an IV is never reused with the same key. Because the salt is new for every message, every message also gets its own key.
- A tag that detects changes. GCM adds a 16-byte authentication tag that covers the encrypted text and, here, the header too. When you decrypt, the tag is checked first, and nothing is shown unless it matches.
- One string to send. The version, the round count, the salt, the IV, the encrypted text and the tag are joined and written as standard Base64. Decrypting needs nothing but that string and the password.
Wrong password or damaged text?
When decryption fails, the tool says the password is wrong or the text was changed, and it cannot say which. That is how AES-GCM works. The decryption function in NIST SP 800-38D returns either the plaintext or a single FAIL, and the Web Crypto spec turns that FAIL into an OperationError. A wrong key and a changed byte produce exactly the same failure.
The tool can still catch some problems before that check. If the text has characters that Base64 does not use, is too short, or has a header that makes no sense, you get a message about the text itself, since no password could fix that. If the header looks fine and the check fails, try these: type the password again with Show on, look out for Caps Lock and spaces at the end, and copy the encrypted text again in full. Line breaks inside the encrypted text are fine; the tool ignores them.
What it protects, and what it does not
Encrypted text is safe to store or send through channels you do not fully trust, as long as the password is strong and stays secret. Be honest with yourself about the limits:
- A weak password can be guessed offline. Anyone who has the encrypted text can try passwords on their own computers, as fast as their hardware allows and without any lockout. The 600,000 rounds make each guess slower, but a common word or a short password still falls. The strength meter, from the password strength checker, flags weak choices, and the password generator makes strong ones.
- The password has to reach the other person safely. The tool does not solve that part. Send it a different way than the text, and do not reuse a password you use for an account.
- It does not replace an end-to-end encrypted messenger. This tool has no way to set up keys between you and the other person. Anyone who learns the password can read every message encrypted with it, past and future.
- Your device must be trustworthy. Encryption cannot protect a message from malware or a person on the computer where you type it.
The format, for developers
The output is standard Base64 of the bytes below. The first 33 bytes are also passed to AES-GCM as additional authenticated data, so changing the version, the round count, the salt or the IV makes decryption fail. The password is normalized to Unicode NFC and encoded as UTF-8, so a letter like ü typed on different systems gives the same key. Decryption here accepts line breaks and URL-safe Base64 as well.
| Bytes | Length | Content |
|---|---|---|
| 0 | 1 | Format version, currently 1 |
| 1 to 4 | 4 | PBKDF2 rounds as an unsigned 32-bit number, big-endian |
| 5 to 20 | 16 | Random salt for PBKDF2 |
| 21 to 32 | 12 | Random IV (nonce) for AES-GCM |
| 33 to end | text + 16 | The encrypted text, then the 16-byte authentication tag |
This Node.js function decrypts it with the built-in crypto module, so your messages do not depend on this site. It throws an error when the password is wrong or the text was changed.
const crypto = require('node:crypto');
function decrypt(base64, password) {
const d = Buffer.from(base64, 'base64');
const key = crypto.pbkdf2Sync(password.normalize('NFC'), d.subarray(5, 21),
d.readUInt32BE(1), 32, 'sha256');
const aes = crypto.createDecipheriv('aes-256-gcm', key, d.subarray(21, 33));
aes.setAAD(d.subarray(0, 33));
aes.setAuthTag(d.subarray(-16));
return Buffer.concat([aes.update(d.subarray(33, -16)), aes.final()]).toString('utf8');
}Base64 on its own is not encryption: the Base64 encoder decodes any Base64 text in a second, no password needed. Here Base64 only packs the encrypted bytes into text that is safe to paste anywhere.
How to use the text encryption tool
- 1Choose Encrypt, type or paste your message, and enter a strong password or tap Suggest a strong passphrase.
- 2Press Encrypt and copy the result. Send it any way you like, and share the password through a different channel.
- 3To read it, choose Decrypt, paste the encrypted text, enter the same password and press Decrypt.
Frequently asked questions
Can anyone see my text or password?
No. Encryption and decryption run in your browser with its built-in Web Crypto API. The page sends neither your text nor your password anywhere and stores nothing, and the share link only remembers whether you were encrypting or decrypting. You can check this in your browser's network tab.
What happens if I forget the password?
The text is lost. The key is computed from the password alone, nothing else is stored anywhere, and there is no reset or back door. Keep the password somewhere safe, such as a password manager.
Why is the result different every time?
Each message gets a new random salt and a new random IV. The salt gives every message its own key, and NIST SP 800-38D requires that AES-GCM never reuses an IV with the same key. So the same text and password give a different result each time, and all of them decrypt to the same text.
Why does it say wrong password or changed text?
AES-GCM checks the password and the encrypted text in one step: it computes a tag and compares it with the one stored at the end. If anything differs, the browser only reports a failure. A wrong password and a single changed character fail the same way, so no tool can tell you which one it was.
Is AES-256-GCM secure?
It is what the OWASP Cryptographic Storage Cheat Sheet recommends: AES, ideally with a 256-bit key, in an authenticated mode, with GCM and CCM named as the first preference. In practice the password is the weak point. A short or guessable password can be found by trying candidates against the encrypted text offline.
How should I share the password?
Use a different way than the one you use for the text: if you email the encrypted text, say the password on a call or send it through another app. Anyone who has both can read the message.
Can I decrypt it without this website?
Yes. The format is documented in the guide below, and a few lines of Node.js decrypt it with the standard crypto module. It uses only standard building blocks: PBKDF2, AES-GCM and Base64.