Text Encrypt / Decrypt

Encrypt text with a passphrase using AES, TripleDES, or Rabbit.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Locks a block of text behind a passphrase and unlocks it again, producing the OpenSSL-style Base64 envelope that other crypto-js and OpenSSL tools can read back.

How to use it

1Choose Encrypt or Decrypt with the two buttons at the top.
2Paste your text, type the shared Passphrase, and pick an Algorithm — AES, TripleDES, Rabbit or RC4.
3Press the Encrypt (or Decrypt) button; the result appears below with a Copy button.

Example

Input: hello — passphrase "correct horse", algorithm AES
Output: a Base64 block beginning U2FsdGVkX1, different on every press

U2FsdGVkX1 is Salted__ encoded: a fresh random salt is prepended each time, so encrypting the same text twice never gives the same ciphertext, and both still decrypt with the same passphrase. The page's own footnote is worth heeding — RC4 and TripleDES are there for legacy interoperability, not because they are still sound.

What happens to your data

The work is done by the crypto-js library bundled into the page, so neither the text nor the passphrase is posted anywhere. The passphrase sits in a type="password" input backed by ordinary React state — not localStorage, not the query string — and closing the tab is enough to be rid of it. A wrong passphrase decrypts to an empty string, and the tool reports "Decryption failed — wrong passphrase, wrong algorithm, or corrupted ciphertext." rather than showing partial plaintext.

Last updated August 2026

You need to put something where you do not fully control who reads it — a shared document, a ticket comment, a note on a laptop other people use — and you would rather it read as nonsense to anyone it was not meant for. Password-based encryption is the small answer to that: one shared secret, text in, gibberish out.

Decide first which of two problems you have. If the recipient already publishes a key, or you need proof of who wrote something, this is the wrong shape — that is public-key territory, PGP or age, where nothing secret has to travel. What this covers is the other case: two people who can agree a passphrase over a channel that is not carrying the message.

That second channel is not a detail, and ignoring it is the common mistake. Pasting the ciphertext and the passphrase into the same thread leaves you where you started. Say the passphrase aloud, or send it through a different application.

The last thing to settle is what will open the result. The output is a standard OpenSSL-style envelope, readable by anything that speaks that format, but the algorithm is not recorded inside it — whoever decrypts must already know which of the four you picked. Agree on AES and leave it alone unless old ciphertext forces your hand.

How it works

Toolvore runs crypto-js inside the page, and the footnote under the controls is the honest version: OpenSSL-compatible key derivation, AES recommended, RC4 and TripleDES present only so legacy ciphertext can still be opened. The derivation is the weak joint. That scheme stretches a passphrase into a key with a single pass of MD5 over the passphrase and a random salt — no iteration count, no memory cost — so it slows guessing by almost nothing, and the only real barrier between your text and someone holding the ciphertext is how unguessable the passphrase was. The envelope carries no authentication tag either, so tampering cannot be told apart from a mistake — both come back as failure or rubbish. Success is judged only by whether the decrypted bytes are valid UTF-8, which is why an empty result and a wrong passphrase are the same event here, and why this shape suits text and nothing else.

Common use cases

Hiding a note inside a document other people can open
Sending a short secret through chat, passphrase by phone
Keeping scratch notes unreadable on a shared machine
Reading back a block produced by openssl enc
Checking old ciphertext still decrypts before retiring a system
Obscuring a spoiler or a puzzle answer in a public thread
Parking a credential in a ticket where plain text breaches policy

Frequently asked questions

Is encrypting text in a browser actually secure?＋

It depends what you are defending against. The cipher is the same AES that runs everywhere else, and doing the work locally means the plaintext never crosses a network. What no browser page can defend against is your own machine — a keylogger, an extension with permission to read pages, someone behind you — all of which sit upstream of any cipher. It cannot prove you were served honest code either — the standing objection to any web page handling secrets. For a note you would rather a passer-by could not read, that is a fair trade; for material whose exposure would be serious, use an audited desktop tool.

How strong does the passphrase need to be, and what if I forget it?＋

Strong enough that guessing it is harder than breaking the cipher, which is a low bar for AES and a high one for people. Because the key comes from the passphrase in a single cheap step, anyone holding your ciphertext can try candidates as fast as their hardware allows, so a word, a name or a date with a digit appended will not last. Four or five unrelated words is the shape that survives. Forget it and nothing recovers the text: no reset, no hint, no recovery code, because nobody but you ever held the key.

Where do my text and my passphrase actually go?＋

Nowhere. The encryption runs in code loaded into the page, so the text, the passphrase and the result exist only in that tab's memory. The passphrase sits in a password field, both live in ordinary component state, and nothing is written to storage or put in the address bar — close the tab and they are gone. Two things do leave the page if you let them: the Copy button writes the result to your system clipboard, where other applications can read it, and whatever you paste in came from that same clipboard. Clear it after handling anything that matters.

Which algorithm should I choose?＋

AES, unless something forces your hand, and the reasons are not close. RC4 has been broken for years and was prohibited in TLS by RFC 7465. TripleDES has a 64-bit block, which is what the Sweet32 attack exploits, and NIST has withdrawn it for new use. Rabbit is not broken, but very little outside crypto-js implements it, so ciphertext made with it is awkward to open anywhere else. The one good reason to reach past AES is that you already have ciphertext made with one of the others and need to read it back.

How do I decrypt this at the command line?＋

The envelope is the one openssl enc reads, but two settings have to match or it will refuse. The digest is the usual trip: crypto-js derives the key with MD5, while OpenSSL 1.1.0 and later default to SHA-256 for that legacy derivation, so the command fails with a bad decrypt error until you add -md md5. Key length is the other: crypto-js uses a 256-bit AES key by default, so pair it with -aes-256-cbc and -base64. Recent OpenSSL also warns that this derivation is deprecated, which is fair comment rather than an error.

Why does decryption fail when the ciphertext looks right?＋

The message names three causes and cannot tell them apart: wrong passphrase, wrong algorithm, or corrupted ciphertext. Algorithm is the one people miss, because nothing in the text records which was used and the failure looks identical to a mistyped passphrase. Corruption is usually transport — a mail client wrapping the Base64 onto fresh lines, a chat app rewriting punctuation, a copy that clipped the last few characters. Whitespace at the very start and end is trimmed before decryption, so that much is handled; breaks in the middle are not.

What is the difference between encryption, encoding and hashing?＋

Encoding rewrites data into a different alphabet so it survives transport. Base64 is encoding, and anyone can undo it with no secret at all, which is why a Base64 string on its own is never protection. Hashing runs data one way into a fixed-length fingerprint that cannot be reversed — it is how passwords should be stored and how downloads are checked, not a way to send a message. Encryption is the reversible one that needs a secret: with the passphrase you get the original back exactly, without it you get nothing. The confusion persists because encrypted output is Base64-encoded afterwards, so it looks like plain encoding.

Is this a substitute for an encrypted messaging app?＋

No, and the gap is key exchange rather than cipher strength. Signal and its peers negotiate keys between devices, rotate them constantly, and authenticate every message so a tampered one is rejected outright. Here you carry the secret yourself and reuse it, so one leaked passphrase opens everything sent with it, and there is no forward secrecy at all. Where this shape earns its place is what those apps leave out: a value that has to sit in a document, a wiki or a ticket for weeks, readable by whoever holds the passphrase and nobody else.