Skip to content
Advertisement

Encrypt / Decrypt Text

Encrypt and decrypt text with a passphrase (AES-GCM/CBC) or an RSA public key — output as Base64.

Crypto Text

Everything stays in this tab

Keys, passphrases, and text are held in memory only — never uploaded, saved, or logged. This is for developer and educational use; for production secrets use vetted, audited tooling.
Direction
Scheme

Settings

How Encrypt / Decrypt Text works

Passphrase encryption here uses AES, a symmetric block cipher: the same key both encrypts and decrypts. Your passphrase is not used as the key directly — it is stretched by a key derivation function with a random salt and a high iteration count, which makes guessing the passphrase expensive rather than instant.

AES-GCM is authenticated encryption. Alongside the ciphertext it produces an authentication tag, and decryption fails outright if a single bit of the ciphertext, the initialisation vector, or the tag has been altered. AES-CBC provides confidentiality only: a modified ciphertext still decrypts, into different plaintext, with nothing to signal the tampering. Prefer GCM unless you must interoperate with something that requires CBC.

Every encryption uses a fresh random initialisation vector. Reusing an IV with the same key under GCM is catastrophic — it can expose the authentication key and reveal relationships between messages — which is why the IV is generated per operation and packaged alongside the ciphertext rather than being a setting you choose.

RSA-OAEP works differently: you encrypt with someone’s public key and only their private key can decrypt. That removes the problem of sharing a passphrase over a secure channel, at the cost of a hard size limit — an RSA key can only encrypt a payload smaller than its modulus, so real systems encrypt a random AES key with RSA and the message with AES.

Reference

  • Key derivation: key = PBKDF2(passphrase, random salt, iterations, 256 bits)
  • AES-GCM output = IV ‖ ciphertext ‖ 128-bit authentication tag
  • RSA-OAEP max plaintext = key size in bytes − 2 × hash length − 2
  • (2048-bit RSA with SHA-256 → 190 bytes maximum)

How to use this tool

  1. Choose a method

    Passphrase (AES) when both sides share a secret; RSA public key when you can only encrypt toward someone else.

  2. Enter the key material

    Type a long, high-entropy passphrase, or paste the recipient’s PEM public key.

  3. Encrypt or decrypt

    Paste your plaintext to encrypt, or Base64 ciphertext to decrypt. The salt and IV travel with the output.

  4. Transmit safely

    Send the Base64 result over whatever channel you like — but never send the passphrase through the same channel.

Worked examples

Sending a credential to a colleague

Given
A short secret encrypted with AES-GCM and a 5-word diceware passphrase
Result
A Base64 blob safe to paste into a ticket or chat

Share the passphrase by a different route — a phone call, not the same chat thread. Otherwise the encryption achieves nothing.

Why GCM over CBC

Given
A ciphertext with one byte flipped
Result
GCM refuses to decrypt; CBC returns corrupted plaintext

The GCM failure is the feature. Silent corruption under CBC is how padding-oracle and bit-flipping attacks get their foothold.

Hitting the RSA size limit

Given
A 400-byte message and a 2048-bit RSA-OAEP key
Result
Encryption fails — the maximum is 190 bytes

This is inherent to RSA, not a bug. Encrypt a random AES key with RSA and the message with AES, which is what TLS and PGP both do.

When to use it

  • Passing a password or API key to a colleague through a channel you do not fully trust.
  • Encrypting a short note before storing it in a shared document or ticket system.
  • Testing that your application’s AES-GCM implementation interoperates with the Web Crypto API.
  • Encrypting a value toward a recipient’s published public key without exchanging any secret first.
  • Demonstrating the practical difference between authenticated and unauthenticated encryption.

Things to watch out for

  • Security rests on the passphrase. Key derivation slows an attacker down; it cannot rescue a short or common passphrase from an offline guessing attack.
  • Lose the passphrase or private key and the plaintext is gone. There is no recovery path, by design.
  • This is a tool for short text, not a file-encryption or disk-encryption system. For files at rest use age, GPG, or your operating system’s encryption.
  • Do not build a protocol on top of this. Rolling your own message format, key exchange, or replay protection is where practical cryptography almost always goes wrong.

Frequently asked questions

Is anything sent to a server?

No. All encryption and decryption uses the browser’s built-in Web Crypto API. Plaintext, passphrases, and keys stay in the page and are never transmitted or stored.

Should I use AES-GCM or AES-CBC?

GCM, unless something you must interoperate with demands CBC. GCM detects tampering and refuses to decrypt modified ciphertext; CBC gives you confidentiality with no integrity, which is a footgun in almost every real design.

How strong does my passphrase need to be?

Strong enough to survive offline guessing, since an attacker with the ciphertext can try passphrases as fast as their hardware allows. Five or six random dictionary words is a reasonable floor; a single word or a short phrase is not.

Why can RSA only encrypt a short message?

RSA encrypts a number smaller than its modulus, and OAEP padding consumes part of that space. A 2048-bit key with SHA-256 tops out at 190 bytes. Real systems use hybrid encryption: RSA protects a random AES key, AES protects the data.

Can I decrypt something encrypted by another tool?

Only if it used the same algorithm, key derivation function, iteration count, and output layout. There is no universal container format for AES ciphertext, so cross-tool compatibility is the exception rather than the rule.

Is this suitable for protecting genuinely sensitive data?

The primitives are sound — it is the same Web Crypto implementation your browser uses for TLS. The weak points are passphrase strength and key handling, which are yours to manage. For high-stakes or long-term secrets, use an audited tool such as GPG or age.

Related Developers tools

All developer tools