Skip to content
TypeParser
All tools

AES Encrypt / Decrypt

AES-GCM encrypt and decrypt.

beats aesencryption.net edge: AES-GCM 256 + passphrase derive
plaintext
ciphertext (base64)
type message + passphrase
Guide

About AES Encrypt / Decrypt

Encrypt and decrypt text with AES-GCM 256-bit using a passphrase. The passphrase is stretched to a 256-bit key via PBKDF2 with a per-message random salt. Output is Base64 with the salt and IV prepended so the same tool decrypts on any machine. All crypto runs in your browser via the Web Crypto API.

When to reach for AES

AES is symmetric encryption — same key encrypts and decrypts. It is fast, well-studied, and the default for most “encrypt at rest” use cases. AES-GCM in particular is authenticated encryption: a wrong key or tampered ciphertext produces an error rather than garbage output. That property closes a large class of bugs.

Use this tool when you need to:

  • Send a one-time secret over an unencrypted channel (DM, email)
  • Store a small secret in a place you do not fully control
  • Test a passphrase-derived encryption flow before writing code

For ongoing secret management, use a dedicated tool — Vault, 1Password, AWS Secrets Manager. They handle key rotation, audit logs, and access control that a one-shot encryption tool does not.

What the tool does, byte by byte

  1. Generate 16 random bytes (the salt).
  2. Stretch passphrase + salt to a 256-bit key via PBKDF2-SHA-256, 250,000 iterations.
  3. Generate 12 random bytes (the IV).
  4. Encrypt with AES-GCM-256 to get ciphertext + 16-byte authentication tag.
  5. Concatenate: salt(16) || iv(12) || ciphertext || tag(16), Base64-encode.

Decryption reverses each step. A wrong passphrase fails at the auth-tag check — no plaintext leaks.

AES encrypt and decrypt in code

This tool uses AES-GCM with a PBKDF2-derived key. The equivalents in common stacks — pin the mode, key size, and KDF explicitly so both ends agree:

Python (cryptography):

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
key = AESGCM.generate_key(bit_length=256)
ct = AESGCM(key).encrypt(nonce, plaintext, None)      # nonce = 12 random bytes
pt = AESGCM(key).decrypt(nonce, ct, None)

OpenSSL (file, CLI):

openssl enc -aes-256-gcm -pbkdf2 -salt -in file -out file.enc
openssl enc -d -aes-256-gcm -pbkdf2 -in file.enc -out file

CryptoJS (JavaScript) — note the default is CBC + OpenSSL MD5 KDF, not GCM:

const ct = CryptoJS.AES.encrypt(text, passphrase).toString();   // legacy default
const pt = CryptoJS.AES.decrypt(ct, passphrase).toString(CryptoJS.enc.Utf8);

C# / .NET — use AesGcm (System.Security.Cryptography) with an explicit 12-byte nonce and 16-byte tag.

Interop gotcha: passphrase-based defaults differ by library (KDF, mode, salt handling). If you must encrypt in one language and decrypt in another, agree on explicit key bytes, IV/nonce, mode (GCM), and KDF (PBKDF2 iterations + salt) rather than passing a bare passphrase. MySQL’s AES_ENCRYPT() uses ECB by default and is the least portable — avoid it for anything cross-system.

Common workflows

Share a one-time secret over Slack. Encrypt with a verbal passphrase, send the ciphertext, share the passphrase out-of-band. Recipient decrypts in their browser.

Store a config token in a non-secure location. Encrypt before commit, decrypt at runtime. The repo carries ciphertext; the operator carries the passphrase.

Test your encryption code. Verify byte-for-byte against the same algorithm in a different language. PBKDF2 + AES-GCM is portable across every modern crypto library.

Why local

Encryption tools that run on a server defeat their own purpose. Whoever runs the server can intercept the plaintext and store the passphrase. This tool runs entirely in your browser via Web Crypto. Open DevTools → Network → confirm: zero requests during encrypt or decrypt.

Frequently asked questions

Is AES-GCM secure?
Yes — it is the standard authenticated encryption mode used in TLS 1.3, modern SSH, and most production secret-management systems. With a 256-bit key, it is not breakable by any known method.
How is my passphrase turned into a key?
PBKDF2-SHA-256 with 250,000 iterations and a random 16-byte salt. Slow enough to make brute-force expensive; the salt ensures identical passphrases on different messages produce different keys.
Are my messages stored?
No. Encryption and decryption run client-side. Refresh the page and the inputs are gone.
Can I decrypt with another tool?
Yes if you replicate the format — 16-byte salt + 12-byte IV + ciphertext + 16-byte GCM tag, all concatenated and Base64 encoded. PBKDF2-SHA-256 with 250k iterations.
Is this safe for storing secrets long-term?
For occasional use, yes. For ongoing secret management, prefer a real secret manager (Vault, AWS Secrets Manager, 1Password) that handles rotation and access control.
Can you decrypt AES-256 without the key?
No. AES-256 with a strong, random key has no known practical attack — recovering the plaintext without the key is infeasible. The only realistic "without key" recoveries exploit a weak passphrase (guessable by dictionary attack) or a leaked/stored key, not a weakness in AES itself. If you have lost the passphrase, the data is effectively gone.
How long would it take to brute-force AES-256?
With a truly random 256-bit key, far longer than the age of the universe on any current or foreseeable hardware — that is the point of 256-bit. The weak link is never the cipher; it is a short passphrase. This tool stretches your passphrase with 250,000 PBKDF2 iterations to raise the cost of guessing, but a strong passphrase still matters most.
Does this interoperate with CryptoJS or OpenSSL?
Only if the other side uses the same construction. This tool uses PBKDF2-SHA-256 (250k) + AES-GCM with salt‖iv‖ciphertext‖tag. CryptoJS's AES.encrypt(text, passphrase) defaults to the legacy OpenSSL EVP_BytesToKey (MD5) KDF with CBC — not compatible. To interoperate, pin both sides to explicit key, IV, and mode rather than relying on passphrase defaults.

Related tools

Last updated: 2026-07-04