Text Encryptor
Encrypt and decrypt text with AES-256-CBC using a passphrase you choose. All encryption runs in your browser — your text never touches a server.
How to Encrypt and Decrypt Text
Features
Why Browser-Based Encryption is Trustworthy
The fundamental security question for any encryption tool is: does it actually keep your data private? For server-side encryption tools, the answer is nuanced — you must trust that the server performs encryption before logging your data and that the server is not compromised. For browser-based encryption using the Web Crypto API, the trust model is simpler: the JavaScript code runs in your browser, and you can verify (using browser developer tools) that no network requests are made during encryption.
The Web Crypto API is a W3C standard implemented natively in Chrome, Firefox, Safari, and Edge. It uses the browser's own cryptographic library (OpenSSL or equivalent) rather than a JavaScript implementation. JavaScript crypto implementations can have timing side-channels; native browser crypto does not.
That said, "native crypto primitives" and "secure system" aren't the same claim. The Web Crypto API gets the low-level cryptography right, but the surrounding design — how the passphrase is handled, whether decrypted text ever touches persistent storage, whether the salt and IV are generated fresh every time — is still up to the tool built on top of it. This tool never writes plaintext, ciphertext, or your passphrase to localStorage, cookies, or any browser storage; everything lives only in memory for the duration of the encrypt or decrypt operation and is gone once you navigate away.
What AES-256 Doesn't Protect You From
Strong encryption is precise about what it guarantees, and it's worth being equally precise about what it doesn't. This tool protects the content of your text from anyone without the passphrase. It does nothing about metadata — the fact that you encrypted something, when you did it, and where you sent the resulting ciphertext are all visible to anyone watching that channel, even though they can't read what's inside. If concealing that you sent an encrypted message matters as much as concealing its contents, that's a different problem this tool doesn't solve.
There's also no authentication built in beyond the passphrase itself. AES-CBC confirms the ciphertext decrypts to something with the right key, but it doesn't cryptographically prove who encrypted it or that the message wasn't altered in transit by someone who also had the passphrase. For most personal and small-team use — encrypting a note, sharing a secret with someone you already trust — this distinction rarely matters in practice. For anything approaching a genuine adversarial threat model, it's worth knowing the guarantee is narrower than "AES-256" alone might suggest.
When to Use Text Encryption
Text encryption is appropriate when you need to store or transmit sensitive information through channels that may not be secure. Use cases: encrypting a private note before storing it in a cloud service you do not fully trust, sending sensitive personal information through email that you need to share with a recipient who has the passphrase, storing a recovery phrase or password as encrypted text in a document, or creating an encrypted backup of sensitive credentials.
For ongoing secure messaging, end-to-end encrypted messaging apps (Signal, WhatsApp) provide a better user experience. For storing passwords, a dedicated password manager is more appropriate than text encryption. This tool is best suited for one-time or infrequent encryption of text notes and small documents.
The common thread across the cases where this tool genuinely fits: text small enough to paste, a recipient (which may be your future self) who already has or can be given the passphrase through a separate channel, and a need that's occasional rather than constant. Once encryption needs to happen automatically, at scale, or as part of an ongoing communication flow, that's a sign to reach for infrastructure built for exactly that rather than a one-off browser tool.
It's also worth checking your recipient's own security posture before relying on this for something genuinely sensitive — the strongest encryption in the world doesn't help if the decrypted text ends up screenshotted, forwarded, or read aloud somewhere it shouldn't be on the other end. Encryption protects the transmission; it can't control what happens after someone legitimately decrypts it.
Choosing a Strong Passphrase
The security of AES-256 encrypted data depends entirely on the passphrase strength. AES-256 itself is unbreakable, but a weak passphrase enables dictionary attacks that test millions of common words and patterns per second. The PBKDF2 key derivation (100,000 iterations) slows dictionary attacks by a factor of 100,000 — but a single common word passphrase can still be cracked in hours on modern hardware.
Best practice: use a passphrase of four or more random words (a "diceware" approach), not a single memorable word. "correct horse battery staple" is far stronger than "password123" despite being easy to remember. Longer passphrases exponentially increase security. Store your passphrase in a password manager — the ciphertext is valueless without the passphrase, and lost passphrases mean lost data.
It's worth resisting the temptation to reuse a passphrase you already use elsewhere, even though it's tempting precisely because it's memorable. A passphrase that also protects an email account or a password manager becomes a single point of failure across everything it protects — if it leaks from one context, every piece of text you've ever encrypted with it is retroactively exposed too, with no way to know how much time has passed since the leak.
Who Needs Browser-Based Text Encryption
Journalists handling sensitive source notes need a quick way to encrypt text without installing software on a work computer. Researchers storing proprietary data in cloud-synced notes want a passphrase-protected layer before content reaches the cloud service. Developers archiving API keys or configuration snippets in shared document systems benefit from encrypting the values first. Small teams without an enterprise secrets manager use AES text encryption as a lightweight alternative for occasionally shared sensitive information.
Because the tool processes everything in the browser, no text is sent to any server — there is no network request when you encrypt or decrypt. This matters for confidential content that should never leave your device unencrypted. For comparing how text looks in other encoded forms, the Text to Binary tool shows hex and binary representations — though those carry no security since they are trivially reversible without a key.
One environment worth calling out specifically: a compromised device undermines all of this regardless of how strong the encryption is. A keylogger or malicious browser extension watching what you type captures the plaintext and the passphrase before encryption ever happens — no cipher, however strong, protects against the input being read at the source. This tool secures data in transit and at rest once encrypted; it can't secure a device that's already compromised, and no browser-based tool honestly can.