HandyTools Hub

AES Encryption Tool

Encrypt and decrypt text securely with a password — AES-GCM 256, fully client-side

Your password is turned into an AES-256 key with PBKDF2-SHA-256 (210,000 iterations) and a random salt. Use a long, unique password — it is never stored or sent anywhere.

The AES Encryption tool encrypts text with a password and decrypts it back, using AES-256-GCM with a key derived by PBKDF2 — all inside your browser via the Web Crypto API. Nothing is uploaded, nothing is stored, and there is no account. It is for the everyday cases where you need to move something sensitive or leave it somewhere: sending a private note through a chat, backing up recovery codes before they go into cloud storage, or keeping a list of credentials out of plain sight.

How to Use

  1. Choose a mode: Encrypt to protect text, Decrypt to restore it.
  2. Enter the input. On encrypt, that is your plain text; on decrypt, paste the complete Base64 payload you received.
  3. Enter the password. Use a long, unique one — it derives the key and is never stored. Length matters more than symbol substitutions.
  4. Run and copy. The result appears immediately; copy the whole payload. For decryption, the original text returns in the output field.

What Happens Behind the Button

The sequence is short but worth knowing, because each step explains a behavior you will notice:

  1. Salt — a random value is generated and stored with the payload so that the same password never produces the same key twice.
  2. Key derivation — PBKDF2-SHA-256 runs 210,000 iterations over your password and the salt, deliberately slow to make guessing expensive.
  3. IV — a fresh random initialization vector is created for this encryption.
  4. Encryption — AES-256-GCM encrypts the UTF-8 bytes of your text with the derived key and IV, and appends an authentication tag.
  5. Output — salt, IV, and ciphertext are packed together and encoded as Base64, which is the string you copy.

The reverse runs the same steps backwards, deriving the key from your password and the stored salt, then decrypting with the stored IV and verifying the tag. If the tag does not match, the tool stops.

Worked Examples

Example 1 — a private message. You need to send account details to a family member over a messaging app. Encrypt the text here, send the Base64 payload in the app, and read the password to them over the phone. An attacker who later gains access to the message history finds only ciphertext.

Example 2 — backup codes. Two-factor recovery codes must be stored somewhere, and a plain notes file in cloud storage is a weak spot. Encrypt the list, keep the ciphertext in the notes app, and store the password in your password manager. The two halves live in different systems, so a breach of one is not enough.

Example 3 — a shared secret in a ticket. A developer needs to hand an API key to a colleague through an issue tracker. Encrypting it keeps the key out of the tracker’s search index and email notifications. Do not put the password in the same ticket — use a separate channel.

What This Protects Against — and What It Does Not

It protects the content of a message in transit or at rest, as long as the password travels separately. It does not protect the fact that you sent something, nor metadata such as timestamps and recipient addresses, nor the destination device. If the recipient’s machine is compromised, the decrypted text is exposed at the destination. And if the password is weak, the 210,000 iterations slow an attacker but cannot save a short or guessable passphrase — encryption inherits the strength of the password you choose.

Choosing the Password

Use a long passphrase or a generated random password, and use a different one for each encrypted item so that a single leak does not unlock everything. A password manager is the practical way to do this: store the encryption password there, because you will not be able to memorize a unique strong password for every note. When someone must type the password rather than paste it — over the phone, for instance — prefer a passphrase of several random words that can be spoken unambiguously.

Common Mistakes

  • Sending the password with the ciphertext. This is the fatal one. Use a second channel.
  • Forgetting the password. There is no reset. Write it down or store it in a manager before you encrypt.
  • Truncating the payload. Copy the entire Base64 string, including any trailing = characters — a missing character makes decryption fail.
  • Editing the ciphertext. GCM authenticates the payload; a stray space added by a chat app can break decryption. If a paste fails, re-copy the exact string.
  • Using a memorable but weak password. Encryption is only as strong as the passphrase, regardless of the AES key size.
  • Assuming a decryption error means a wrong password. It can also mean the payload was altered. Check the copy before concluding the password is at fault.

Features

  • AES-256-GCM authenticated encryption with tamper detection
  • PBKDF2-SHA-256 key derivation, 210,000 iterations, random salt
  • Fresh IV for every encryption — identical input never yields identical output
  • Full UTF-8 support, including accented characters and emoji
  • One-click copy of the complete Base64 payload
  • 100% client-side via the Web Crypto API — no uploads, no logs, no storage

Frequently Asked Questions

What exactly happens when I click Encrypt?

Your password is run through PBKDF2-SHA-256 with 210,000 iterations and a random salt to derive a 256-bit key. A fresh random IV is generated, and AES-GCM encrypts the text with that key and IV. The output packages the salt, IV, and ciphertext together as a Base64 payload, which is what you copy.

Can I recover my text if I forget the password?

No. There is no recovery path, no reset link, and no escrow — the key exists only for the moment you derive it. This is the point of client-side encryption: nobody, including this site, holds a copy of your password or a way to bypass it. Store the password somewhere safe before encrypting anything you cannot afford to lose.

Is it safe to send the ciphertext and the password over the same channel?

No, and this is the single most common mistake with any manual encryption tool. Sending the encrypted payload by email and the password by the same email defeats the entire exercise. Deliver the password through a different channel — a phone call, a password manager share, or an in-person exchange — so an attacker who captures one message still has nothing.

Does encrypting the same text twice give the same result?

No. A new random salt and IV are generated for each operation, so encrypting 'hello' twice produces two different Base64 strings. That is a security feature: identical ciphertexts would reveal that two messages are the same. Both outputs decrypt back to the original with the correct password.

What is AES-GCM, in one paragraph?

It is an authenticated encryption mode: it both hides the content and detects any tampering. If a single character of the payload is changed in transit, decryption fails with an error rather than returning corrupted plaintext. That is also why the tool cannot tell you whether your password was wrong or the payload was damaged — from the cipher's point of view, both look like failed authentication.

Should I use this for long-term archival?

Use caution. The format depends on this tool's parameters remaining documented and reproducible, and a lost password is unrecoverable. For archives meant to last decades, prefer a well-known standard tool such as age, GPG, or your operating system's encrypted container format, and store the password in a manager plus a written backup in a safe place.

Reviewed by the HandyTools Hub team · Last updated