Skip to content
ToolBoxGeniehome

Text Encrypter

Developer Tools · Added

Turn a message into a block of Base64 that only your passphrase reopens, using the browser's own Web Crypto implementation of AES-256-GCM. The block carries its own salt, initialisation vector and key-derivation cost, so a message encrypted today still opens years from now, on another machine, whatever this page does next. One thing is worth being blunt about: the passphrase is the entire security of the message.

What do you want to do?

Up to 200,000 characters.

There is no recovery. Lose this and the message is gone for good.

Key derivation runs 600,000 PBKDF2-SHA256 iterations, so expect a short pause. That delay is the point: it is paid once by you and once per guess by anyone attacking the message.

How to use the text encrypter

  1. 1Choose Encrypt, type or paste your message, and pick a passphrase — several unrelated words beat one clever word.
  2. 2Press Encrypt and wait for the short pause while the key is derived.
  3. 3Copy the whole Base64 block, every line of it, and send it however you like.
  4. 4To read one, choose Decrypt, paste the block, enter the passphrase and press Decrypt.

Examples

A short note

Input
A 32-character message with a four-word passphrase
Result
A 117-character Base64 block over two lines

Overhead is fixed: 37 bytes of header plus a 16-byte authentication tag, so short messages look proportionally larger.

A wrong passphrase

Input
The correct block, one character different in the passphrase
Result
A refusal to decrypt — never partial or garbled output

An altered message

Input
The correct passphrase, with six characters of the block edited
Result
The same refusal: AES-GCM authenticates, so tampering fails the check a wrong passphrase fails

About the text encrypter

Why the parameters travel with the message

A passphrase is not a key. Turning one into a 256-bit AES key needs a salt and a cost setting, and decryption needs the exact same values — which means they have to be stored somewhere. Tools that hard-code them break the day the defaults change: raise the iteration count and every message written under the old number becomes unreadable.

So the block here describes itself. It states its format version, the iteration count that derived its key, its salt and its vector, before a single byte of ciphertext. Nothing about opening an old message depends on a default in today's code matching the default in the code that wrote it.

The salt is what stops one precomputed table attacking every message at once, and it is random per message rather than per passphrase. The vector is random per message for a stricter reason: reusing one with the same key in GCM does not merely weaken the encryption, it can expose the authentication key outright.

Authenticated encryption, and why it refuses

Older tools often used AES-CBC, which encrypts but does not authenticate. Feed one a wrong key and it happily returns plausible-looking bytes; feed it a message an attacker has modified and it returns the modification without comment. A whole family of padding-oracle attacks lives in that gap.

GCM closes it by computing an authentication tag over the ciphertext and checking that tag before returning anything at all. That is why this page has exactly two outcomes — the original message, or a refusal. It is also why the refusal is worded as it is: the check that failed cannot report which of its two possible causes applied.

The passphrase is the whole of it

Everything above concerns bytes an attacker can see. What actually decides whether a message stays private is how the passphrase was chosen, because an offline attacker does not attack the cipher — they guess, in order of likelihood, as fast as the key derivation lets them.

The strength meter on this page measures the size of the keyspace implied by the character sets you used. It cannot tell whether the phrase already sits in a word list, and it will happily rate a famous example passphrase highly. Treat it as a floor rather than a verdict, and remember there is no reset link here: lose the passphrase and the message is gone.

Frequently asked questions

How strong is this, honestly?
The cipher is not the weak point: AES-256-GCM with a random 96-bit initialisation vector per message is what TLS uses. The passphrase is. Key derivation runs 600,000 PBKDF2-SHA256 iterations, which makes each guess expensive, but expensive is not impossible — a passphrase from a word list falls to an offline attack whatever the iteration count. Four or five unrelated words is the practical bar.
What exactly is in the output block?
A four-byte marker, a format version, the iteration count, a 16-byte random salt, a 12-byte random initialisation vector, then the ciphertext with its 128-bit authentication tag — all Base64-encoded and wrapped at 72 columns. Salt and vector are random per message and must travel with it. The passphrase is not in there and cannot be recovered from it.
Is any of this sent to a server?
No. Both directions run in this tab through the browser's Web Crypto API. The page makes no network request with your message or your passphrase, and closing the tab discards both. What you do with the block afterwards is outside what this page can promise.
Why can it not say whether the passphrase was wrong or the message was damaged?
Because the primitive genuinely cannot. AES-GCM verifies one authentication tag over the ciphertext, and a wrong key and an altered byte both fail that single check. A tool claiming to tell them apart would be guessing. The upside is the guarantee it does give: output is either exactly what was encrypted or nothing at all.
When should I not use a page like this?
When you need more than a shared secret. There is no identity here and no signature, so a message proves only that somebody knew the passphrase; there is no forward secrecy, so one leaked passphrase opens every message it ever protected. For ongoing correspondence use an end-to-end messenger, and for files use age or GnuPG.

Related tools