AES-256 Text Encryption Explained in Plain English

You want to send someone a password, an API key or a private note, and the only channel you have is email or a chat app. You can paste the plain text and hope. Or you can encrypt it first, so the message is unreadable to anyone who intercepts it, and share the passphrase another way.

That is what Text Encryptor is for. Here is what happens between "type passphrase" and "get a block of letters", without the jargon.

The problem: a passphrase is not a key

AES needs a key of exactly 256 bits, which is 32 bytes of random-looking data. A passphrase like "correct horse battery staple" is neither the right length nor random. If you used it directly, short passphrases would produce weak, predictable keys.

The fix is a key derivation function. The tool uses PBKDF2 with a random salt and 100,000 iterations. It hashes the passphrase with the salt, then hashes the result again, 100,000 times. The output is a uniform 256-bit key.

Why bother with so many rounds? An attacker who steals your ciphertext can try passphrases one by one. Each attempt costs them 100,000 hash operations instead of one, which slows a guessing run by that same factor. The salt prevents them from reusing precomputed tables across different messages.

The cipher: AES-256-GCM

The derived key feeds AES-256-GCM. Two parts of that name matter.

• AES-256 is the cipher. The 256-bit key gives a key space of 2 to the power of 256 possibilities, far beyond what any brute-force search can cover.
• GCM (Galois/Counter Mode) is the mode. It turns AES into a stream-like cipher and adds an authentication tag. If a single byte of the ciphertext changes, decryption fails with an error. You never get silently corrupted plaintext.

A fresh random initialisation vector (IV) is generated for every message. Reusing an IV with the same key in GCM is a serious mistake, so the tool creates a new one each time.

What ends up in the output

The result is one block of base64 text containing the salt, the IV and the ciphertext packed together. None of the three is secret by itself. The salt and IV only need to be unique and available at decryption time. The only secret is the passphrase.

This is why you can safely paste the output into an email, a note or a chat. If you are curious how binary data becomes text you can paste, see Base64 encoding: what it's for. Note that Base64 is an encoding, not encryption: it hides nothing on its own.

How to encrypt and decrypt text

1. Open Text Encryptor.
2. Type or paste the message.
3. Enter a passphrase. Generate one with the Passphrase Generator or Password Generator rather than inventing it.
4. Choose encrypt and copy the output block.
5. Send the block through any channel, and share the passphrase through a different one.
6. To read it, the recipient pastes the block into the same tool, enters the passphrase and chooses decrypt. A wrong passphrase or an altered block shows an error, not nonsense.

Benefits

• No server involved. The work is done by the browser's Web Crypto API on your device, so neither the text nor the passphrase is transmitted.
• Standard algorithms. AES-GCM and PBKDF2 are well-studied, widely deployed standards, not a home-made scheme.
• Tamper detection. You find out if the message was modified in transit.
• Works anywhere text works. Email, SMS, wikis, tickets, even a printed page.

Where current tools fall short

Many "encrypt text online" pages send your text to a server to encrypt it, which defeats the point. Others use weak or old schemes, give no detail on the algorithm, ask you to create an account, or limit message length. Some produce output that only their own site can decrypt. When a tool does not say what algorithm and key derivation it uses, assume the worst. A good test: the page should work offline once loaded, and it should name the algorithm.

What this protects against, and what it does not

Protects against:

• Someone reading an email or note that was intercepted or left in a shared inbox.
• A leaked chat export.
• Casual snooping on a file that contains the block.

Does not protect against:

• A weak passphrase. The 100,000 rounds slow guessing, but a one-word passphrase is still guessable. See strong passwords vs passphrases.
• A compromised device. Malware, a keylogger or someone looking at the screen while the plaintext is visible.
• Metadata. The existence of the message, its approximate length, and who exchanged it are not hidden.
• Lost passphrases. There is no recovery.

Everyday situations

• Sharing a Wi-Fi or router password with a contractor.
• Sending an API key to a colleague without leaving it in plain text in chat history.
• Keeping a private note in a shared document or notes app.
• Passing a recovery code to a family member for emergencies.
• Storing a snippet that must not be readable if a laptop is lent out.

Tips and mistakes to avoid

• Use a long passphrase, at least four random words.
• Send the passphrase separately, ideally by a different medium.
• Do not encrypt and forget. Test the decrypt step before you delete the original.
• Do not confuse hashing with encryption. A hash such as SHA-256 cannot be reversed; see SHA-256 hash explained and the Hash Generator.
• Keep software updated. The cipher is only as safe as the browser that runs it.
• Never share the output and the passphrase in the same message.

A worked example of the whole flow

Imagine you need to give a contractor the password for a staging server. You open Text Encryptor, paste the server password, and enter the passphrase "lantern-orbit-marble-fox-41", which you generated rather than invented. The tool returns a block of about 60 to 100 characters of base64 text. You paste that block into an email.

Separately, you phone the contractor and read the passphrase out. They paste the block into the same tool, enter the passphrase, and see the server password. If they mistype a single character of the passphrase, they get a decryption error, not a wrong answer. If someone alters the block in transit, the authentication tag fails and they get the same error.

An outsider who reads the email sees only the block. They would need the passphrase, and the only way to find it is to guess, one attempt at a time, each costing 100,000 rounds of hashing.

Why random salts and IVs matter

Both values are random for every message, which has useful consequences. Encrypting the same text twice with the same passphrase yields different output each time, so an observer cannot tell whether two messages are the same. And because the salt changes, the same passphrase leads to a different key each time, which stops an attacker from reusing work across messages.

You do not have to keep the salt or IV secret, and you do not need to store them separately: they travel inside the output block. That is a design choice, not a weakness. What must be kept secret is only the passphrase.

How strong is "strong enough"?

The 256-bit key is not the limiting factor; the passphrase is. A passphrase of four words picked at random from a list of about 7,000 words gives roughly 50 bits of guessing difficulty (7,000 to the power of 4 is about 2.4 times 10 to the 15). Five words gives about 63 bits. With 100,000 hashing rounds per guess, those figures put casual and even determined offline guessing out of practical reach, while a single dictionary word falls almost at once. This is why the advice is always the same: use a long random passphrase, and let the cipher do the rest.

Related reading

For the broader case for doing this on your device, read why client-side tools matter. To protect whole documents instead of text, see how to password protect a PDF. More tools are on the security tools page.