Encrypt / Decrypt Text

Encrypt a block of text with a password using AES, TripleDES, or RC4, and decrypt it again later with the same password — entirely inside your browser tab, with the plaintext, ciphertext, and password never transmitted anywhere.

Why running this locally isn’t optional, it’s the entire point

Of every tool on this site, this is the one where server-side processing would be most self-defeating. If you’re encrypting text specifically because it’s sensitive — a password, a private note, a confidential message — sending that plaintext to a server before encrypting it defeats the purpose before encryption even happens, regardless of what the server claims to do with it afterward. This tool performs encryption and decryption using your browser’s own JavaScript cryptography libraries, so the plaintext, the resulting ciphertext, and your password all stay on your device throughout the entire process.

How to use it

1. Choose Encrypt or Decrypt mode.
2. Select your algorithm — AES (the modern, generally recommended standard, used in most current security-conscious applications), TripleDES (older, still functional but with a smaller effective key strength than AES), or RC4 (a legacy stream cipher included mainly for compatibility with older systems, and not recommended for new sensitive data given known cryptographic weaknesses).
3. Enter your plaintext and a password, and the tool encrypts it into ciphertext you can safely copy, share, or store.
4. To decrypt, paste the ciphertext back in along with the exact same password used to encrypt it — get the original plaintext back, or a clear error if the password doesn’t match.
5. Choose the output encoding for the ciphertext (Base64 is the default and most portable choice for pasting into text-based systems, with hex also available for contexts that specifically expect it).

Common situations this solves

• Sending a sensitive piece of text through a channel you don’t fully trust (like pasting into a shared document or an unencrypted messaging platform) by encrypting it first with a password shared separately through a different channel.
• Storing a sensitive note in a place that isn’t itself encrypted (a plain text file, a non-encrypted note app) by encrypting the content before saving it there.
• Testing or debugging code that implements AES, TripleDES, or RC4 encryption, using this tool as an independent reference to verify your implementation produces matching output for the same input and password.
• Understanding the practical difference between these algorithms by encrypting the same text with each and comparing the resulting ciphertext and behavior.
• Sharing a password-protected message with someone where you can communicate the decryption password out-of-band (a phone call, in person) separately from the encrypted text itself.

Frequently asked questions

Which algorithm should I actually use — AES, TripleDES, or RC4?

AES is the right default for essentially any new use case — it’s the current industry standard, used in everything from HTTPS to disk encryption, and offers the strongest security of the three when used correctly. TripleDES and RC4 are included primarily for compatibility with older systems or legacy data that was originally encrypted with them; RC4 in particular has known cryptographic weaknesses and shouldn’t be chosen for new sensitive data if AES is an option.

Is this the same as password hashing, like what a login system uses to store passwords?

No — this is genuinely reversible encryption, meaning anyone with the correct password can recover the exact original text. Password storage for authentication systems should instead use one-way hashing (via a dedicated tool like a proper Hash generator combined with salting and iteration, not simple encryption), since a login system should never be able to recover a user’s actual original password, only verify a match.

How strong does my password need to be for this encryption to actually be secure?

Very strong — the security of the encrypted output is fundamentally limited by the strength of the password used, regardless of how strong the underlying algorithm is. A weak, short, or guessable password undermines even AES significantly, since an attacker can attempt to guess passwords rather than needing to break the algorithm itself. Consider using the Password generator to create a strong, random password specifically for this purpose if the destination system allows you to store or share it appropriately.

If I lose or forget the password, is there any way to recover the original text?

No, and this is intentional — the entire security guarantee of encryption depends on the fact that the text cannot be recovered without the correct password. There’s no backdoor or recovery mechanism, so treat the password with the same care you’d give the original sensitive text itself, since losing it means permanently losing access to the encrypted content.

Can I verify this tool isn’t sending my plaintext or password anywhere before I trust it with something sensitive?

Yes — open your browser’s developer tools network tab before using the tool, and you’ll see no outbound network requests triggered by encryption or decryption, since the entire process runs using JavaScript cryptography libraries loaded once with the page and executed locally afterward with no further server communication needed.