Fast, practical, browser-based developer tools
Encrypt and decrypt text online using AES directly in your browser. Enter your secret key, encrypt plain text instantly, decrypt ciphertext, then copy or download the output for testing, development, demos, and lightweight secure workflows.
AES is one of the most widely used symmetric encryption standards. This tool helps you run quick encryption and decryption tasks without installing software, making it useful for learning, debugging, testing, development workflows, and lightweight browser-based text protection tasks.
This AES tool is designed to work directly in your browser during normal use. That makes it useful for fast testing, demos, and lightweight local workflows.
For more details about site usage and analytics, read our Privacy Policy.
Enter your passphrase, type or paste the text you want to encrypt or decrypt, then choose the action you need. You can copy the result immediately or download it as a TXT file.
• Encrypt text with a passphrase • Decrypt AES ciphertext • Copy the output instantly • Download output as TXT • Test AES flows in the browser
AES, the Advanced Encryption Standard (NIST FIPS 197, standardised in 2001 from the Rijndael cipher), is a block cipher: it transforms exactly one 16-byte block at a time under a 128-, 192-, or 256-bit key. As a primitive it is not broken. There is no practical attack meaningfully better than brute force, and brute-forcing even a 128-bit key is far beyond any computer that will ever exist. When AES fails in the real world, the cipher is almost never the reason.
The catch is that a single 16-byte block is smaller than almost any real message, so you
need a mode of operation to chain blocks together — and the mode is the
part people get wrong. Saying you "used AES" tells you almost nothing about whether your
data is safe. AES-256-GCM and AES-128-CBC are the decisions that
actually matter, and they behave very differently.
ECB (Electronic Codebook) encrypts each block independently, so identical plaintext blocks become identical ciphertext blocks. Patterns in your data survive encryption. The classic demonstration is encrypting a bitmap of the Linux penguin in ECB: the outline of the penguin is still plainly visible in the "encrypted" image. Never use ECB for anything real.
CBC (Cipher Block Chaining) fixes the pattern problem by XORing each block with the previous ciphertext block before encrypting, so repeated plaintext no longer repeats in the output. But CBC brings two traps. First, its initialization vector (IV) must be random and unpredictable for every message — a predictable IV enabled the BEAST attack against TLS. Second, and more important: CBC provides confidentiality but no authentication. An attacker can tamper with ciphertext, and if your code reveals whether decryption produced valid padding, a padding-oracle attack can recover the entire plaintext without ever knowing the key.
AES-GCM (Galois/Counter Mode) is an AEAD — authenticated
encryption with associated data. In one pass it encrypts the data and produces an
authentication tag. On decryption, if the tag does not verify, you get an error instead of
garbage plaintext. That single property closes off the entire padding-oracle and
bit-flipping class of bugs that haunts CBC, which is why GCM (or ChaCha20-Poly1305) is the
modern default.
GCM has one rule you cannot break: never reuse a nonce (IV) with the same key. This is not a "your two messages leak into each other" problem, though that happens too. Reusing a nonce under one key lets an attacker recover GCM's internal authentication subkey, after which they can forge a valid tag for any message they like. One nonce collision compromises the integrity of everything encrypted under that key, not just the two colliding messages. Use a fresh random 96-bit nonce per message, or a strict counter, and rotate keys well before you could approach a birthday-bound collision.
AES-256 needs 256 bits of key. A human passphrase is neither the right length nor anywhere near 256 bits of entropy, so handing a raw string to a cipher as its "key" is a mistake. Stretch the password into a key with a slow, salted key-derivation function — PBKDF2, scrypt, or Argon2 — using a unique random salt per encryption and a deliberately high work factor.
The reason the KDF must be slow is the same reason you never store passwords with a
fast hash: a single SHA-256 of the password produces 32 bytes instantly, which
means an attacker who captures your ciphertext can also guess billions of candidate
passwords per second. A tuned Argon2 or PBKDF2 with a high iteration count makes each guess
expensive, which is the entire point.
This page uses the CryptoJS library in passphrase mode. Under the hood that is
AES-256-CBC in the OpenSSL-compatible Salted__ format: a random
8-byte salt per encryption, with the key and IV derived from your passphrase by
EVP_BytesToKey — a single MD5 pass. That is perfectly good for learning how
symmetric encryption round-trips and for moving test data around, but by modern standards
the key derivation is weak and CBC gives you no tamper detection.
Treat this as a testing and learning tool, not a vault. Do not protect real secrets with it,
and — the more important lesson — do not hand-roll your own scheme for production. Reach for
a maintained library, use AES-GCM, and derive the key with Argon2 or PBKDF2.
No. The best known attacks on the AES primitive shave off only a couple of bits of security and remain entirely theoretical; a 128-bit key is beyond brute force. Real AES failures come from the surrounding choices — the mode of operation, IV or nonce handling, and how the key was derived — not from the cipher.
GCM. It authenticates as well as encrypts, so tampering is detected and the padding-oracle attacks that plague CBC do not apply. Use CBC only when you must interoperate with something that requires it, and then pair it with a separate HMAC using an encrypt-then-MAC construction.
It is a per-message value that makes encrypting the same plaintext twice produce different ciphertext. For CBC it must be random and unpredictable; for GCM it must be unique for every message under a given key. Reusing a GCM nonce under one key is catastrophic — it exposes the authentication key and lets an attacker forge messages — so never reuse one.
No. Run it through PBKDF2, scrypt, or Argon2 with a unique random salt to stretch it
into a key. A raw password is the wrong length and too low in entropy, and a single
SHA-256 of it is far too fast to resist offline guessing.
Only if the mode authenticates. Plain CBC and ECB provide confidentiality but not integrity: an attacker can alter the ciphertext and you will not detect it, which is exactly what padding-oracle attacks exploit. Use an AEAD mode such as GCM, or add an HMAC over the ciphertext.
Use it for testing and learning. It relies on CryptoJS passphrase mode — AES-CBC with a single-MD5 key derivation — which is unauthenticated and uses a weak KDF, and any browser tool handles the key client-side. For production, encrypt with a maintained library using AES-GCM and a proper KDF like Argon2 or PBKDF2.