Online Tool Store
Text Encryptor
Encrypt a message to someone using their RSA public key, with no shared secret needed. Uses hybrid RSA-OAEP plus AES-256-GCM in your browser, so message length is unlimited and tampering is detected. Generates key pairs as PEM.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Keys are generated and used entirely in your browser using Web Crypto, and nothing is transmitted or stored. Encryption proves nobody else can read the message; it does not prove who sent it, because anyone with the public key can encrypt to it.
How to use it
- Generate a key pair, then save the private key somewhere safe — it is not stored here.
- Send your public key to whoever needs to write to you. It is safe to publish.
- They paste it in, type a message, and send you the encrypted block.
- You paste your private key and that block into the decrypt tab.
Why public-key, when a password is easier
Password-based encryption has a circular problem: to send someone an encrypted message you must first send them the password, and if you had a safe channel for the password you could have used it for the message. In practice the password goes by text message or email alongside the file, which undoes most of the protection.
Public-key encryption removes that step. Your public key can go in an email signature, a profile, a website — anywhere, because knowing it only lets someone write to you, never read. The private half never leaves your machine and never needs to be transmitted at all.
The trade-off is key management: you have a private key to look after, and losing it means losing everything encrypted to it. If you and the recipient already share a passphrase safely, a password-based tool is simpler and just as secure for that purpose.
RSA cannot carry your message
This is the constraint that shapes the whole design. RSA-OAEP can only encrypt a payload smaller than its key, minus room for
padding — precisely keyBytes − 2 × hashBytes − 2:
RSA-2048 + SHA-256 → 190 bytes maximum
RSA-3072 + SHA-256 → 318 bytes
RSA-4096 + SHA-256 → 446 bytes
That is a hard edge, not a guideline: at 2048 bits a 190-byte message encrypts and a 191-byte message fails with an error. Two sentences of text would already be too long.
So the standard approach, used here, is hybrid encryption. A fresh random AES-256-GCM key encrypts the actual message, and RSA is used only to wrap that 32-byte key. The consequence is a fixed overhead — 256 bytes of wrapped key plus a 12-byte initialisation vector — regardless of message length. Fifty thousand characters round-trip exactly as reliably as five, which was verified rather than assumed.
Encryption is not authentication
Worth stating clearly because it is a common and consequential misunderstanding. Anyone who has your public key can encrypt a message to you, and your public key is meant to be public. So the fact that a message decrypts tells you that it was encrypted to your key — and nothing whatsoever about who wrote it.
What the tool can tell you is that the message has not been altered since it was encrypted, because AES-GCM verifies an authentication tag before releasing any plaintext. Flip one bit of the ciphertext and decryption fails outright instead of returning corrupted text that looks real — verified. Proving authorship requires a digital signature made with the sender's own private key, which is a different operation and not one this tool performs.
The honest limits of doing this in a browser
The cryptographic primitives here are the browser's own Web Crypto implementation — the same code your bank's site relies on, and not something reimplemented for this page. That part is trustworthy.
The part that is not is the delivery. A web page is served fresh every time and can in principle be changed by whoever controls the server, and you have no realistic way to audit the script that just ran. Nothing here is transmitted or stored, which you can confirm in your browser's network tab, but that is a check on this visit rather than a guarantee about the next one.
The reasonable conclusion is not that browser cryptography is useless — it is that the threat model matters. Sending a moderately private note through a channel you do not trust is a good fit. Protecting information whose disclosure would genuinely harm someone calls for audited software you installed and can verify, and a key that has never been near a web page.
FAQ
How is this different from the AES password tool?
It solves a different problem. Password-based encryption requires both people to already share a secret, which means finding a safe way to send the password — often the hardest part. Here you publish a public key, anyone can encrypt a message to you with it, and only your private key can decrypt. No secret ever has to travel. If you and the recipient already share a passphrase, the AES tool is simpler and entirely sufficient.
Why is there an AES key inside an RSA-encrypted message?
Because RSA cannot carry much data. With a 2048-bit key and SHA-256 the ceiling is exactly 190 bytes — we checked, and 190 succeeds while 191 fails outright. So the message is encrypted with a fresh random AES-256-GCM key and RSA is used only to wrap that key, which is 32 bytes. This is standard practice rather than a shortcut, and it means the RSA overhead is a fixed 256 bytes no matter whether you send a sentence or fifty thousand characters.
Does an encrypted message prove who sent it?
No, and this is a genuine limitation rather than a detail. Your public key is public, so anybody at all can use it to encrypt something to you. Successful decryption proves only that the message was encrypted to your key — not who did it. Proving authorship needs a digital signature, which is a separate operation this tool does not perform. Do not treat a decryptable message as authenticated.
What happens if I lose the private key?
Everything encrypted to the matching public key becomes permanently unreadable. There is no recovery, no reset and no back door — that is what makes the encryption worth anything. The key is generated in your browser and never transmitted or stored anywhere, including here, so if you close the tab without saving it, it is gone.
Will it tell me if a message was tampered with?
Yes. AES-GCM is an authenticated mode, so it verifies an integrity tag before returning anything. Change a single bit of the ciphertext and decryption fails outright rather than producing plausible-looking rubbish — verified. That is a meaningful property: with an unauthenticated cipher, a modified message can decrypt to something that looks legitimate.
Can I trust a web page with real secrets?
For anything genuinely sensitive, no — and that is worth saying plainly rather than burying. The cryptography itself is your browser's Web Crypto implementation and is sound; the problem is that a page can be changed by whoever serves it, and you have no practical way to verify the code you just ran. For moderately private material sent over an untrusted channel this is a reasonable tool. For information whose disclosure would be serious, use audited software you installed yourself and can verify.
How we compare
| Feature | Online Tool Store | A password-based encryptor | GPG on your own machine |
|---|---|---|---|
| No shared secret has to travel | ✓ | ✗ | ✓ |
| Keys and text never leave the browser | ✓ | Depends | ✓ |
| Detects a tampered message | ✓ | If authenticated | ✓ |
| Nothing to install | ✓ | ✓ | ✗ |
| Proves who sent the message | ✗ | ✗ | ✓ |
| Code you can audit and pin | ✗ | ✗ | ✓ |
| Key servers, web of trust, revocation | ✗ | ✗ | ✓ |
This exists for the case where you want public-key encryption once, without installing anything and without teaching the other person to use GPG. It does not sign, does not manage or revoke keys, and cannot offer the auditability of software you control. If you need any of those, or the material is genuinely sensitive, use GPG or an equivalent — and if you already share a passphrase safely, a password-based tool is the simpler choice.