All posts
June 7, 20266 min read

Encrypting text in your browser with AES

Encoding and encryption get confused constantly, so start here. Base64 rearranges bytes into text that any system can carry, and anyone can reverse it with no secret at all. It hides nothing. Encryption transforms data so that only someone holding the right key can recover the original. The difference is the key. If reversing a transformation needs no secret, it is encoding, not encryption.

What symmetric AES encryption is

AES, the Advanced Encryption Standard, is a symmetric cipher. Symmetric means the same key both locks and unlocks the data. You encrypt a message with a key, and the only practical way back to the plaintext is that same key. AES is the workhorse of modern cryptography, trusted for everything from disk encryption to HTTPS.

A common, sound configuration is AES-256-GCM. The 256 is the key size in bits. GCM is a mode that does two jobs at once: it keeps the data confidential and it produces an authentication tag that detects tampering. If even one byte of the ciphertext is altered, decryption fails loudly instead of returning quietly corrupted text. That authenticity check matters as much as the secrecy.

Your passphrase is the security

Here is the part people underestimate. AES itself is not the weak point. The weak point is almost always the passphrase. A tool typically turns your passphrase into a key using a key derivation function such as PBKDF2, which deliberately runs slowly to make guessing expensive. But no derivation step can rescue a weak passphrase.

weak:   summer2024        guessed in seconds
weak:   correcthorse      a famous phrase, in every wordlist
strong: 6 random words from a large list, or a long unique string

Practical guidance:

  • Use a long passphrase, ideally several unrelated random words or a string from a password manager.
  • Do not reuse a passphrase you use elsewhere.
  • Remember that if you lose the passphrase, the data is gone. There is no recovery and no reset. That is the point.

Why client side encryption matters

When encryption runs entirely in your browser, the plaintext and the passphrase never travel anywhere. Nothing is uploaded, logged, or stored on a server. The bytes are processed locally by the browser's built in Web Crypto API, and only the ciphertext exists to be copied out. This is the privacy promise of doing the work in the browser: there is no server that could leak what it never received.

Sensible uses and honest limits

Good uses include sending a sensitive note where you can share the passphrase through a separate channel, stashing a secret in a file you do not fully control, or encrypting a value before pasting it somewhere semi public.

The limits are real and worth stating plainly:

  • Key exchange is your problem. Symmetric encryption assumes both sides already share the key. Sending the passphrase next to the ciphertext defeats the entire exercise.
  • It is not signing or identity. Encryption proves nothing about who created the message, only that whoever holds the key can read it.
  • It does not protect a compromised device. If malware sits on your machine, it can read the plaintext before you ever encrypt it.
  • It is not the same as password storage. Passwords should be hashed, not encrypted. Reach for the Hash Generator for that, and for message authentication the HMAC Generator is the right tool.

To encrypt or decrypt a string with a passphrase, the Encrypt / Decrypt Text tool uses AES-256-GCM through the Web Crypto API. The text and the passphrase stay in your browser and are never transmitted. If you have data that only needs to be made text safe rather than secret, that is a job for the Base64 Encode / Decode tool instead.