AES encryption and decryption

This tool encrypts and decrypts AES-128, AES-192 and AES-256 using CryptoJS. The results are interoperable with AES implementations in Java, PHP, Python and other backends.

Everything runs in your browser. Your data never leaves the page, and keys are never stored or sent to a server.

Features:

• Encrypt: enter plaintext and click Encrypt. The ciphertext appears in the result box.
• Decrypt: enter ciphertext and click Decrypt. Base64 and hex are detected and tried automatically.
• Separate input and output: the result box is read-only, so your original input stays intact for comparison.
• Modes: ECB, CBC, CFB, CTR, OFB and GCM. The stream modes (CFB/CTR/OFB) always use NoPadding. GCM works best with a 12-byte IV (other lengths trigger a warning) and outputs IV + ciphertext + tag, matching GCM in Java, Go and Python.
• Padding: ECB and CBC support PKCS7, AnsiX923, Iso10126, Iso97971, ZeroPadding and NoPadding.
• Key length: keys must be 16, 24 or 32 bytes (AES-128/192/256). The tool reports the actual byte count and blocks any other length.
• Charset: plaintext is encoded with the selected charset, as are text-format keys and IVs; hex and Base64 values are decoded directly. UTF-8 is the default. GBK suits legacy Simplified Chinese systems (2 bytes per character), GB18030 covers all CJK characters plus rare ones and emoji (up to 4 bytes), and Latin-1 maps each character to one byte.
• IV: the IV uses the same format as the key. Most modes need 16 bytes, GCM works best with 12. Use the Random button beside the label to generate one of the right length. For GCM ciphertext produced here, leave the IV blank to read the 12-byte IV embedded at the start, or enter the IV used to encrypt. Other modes always need the IV.
• AAD: shown for GCM only and optional. It is covered by the authentication tag but not encrypted, so it must match exactly on decrypt. Leave it blank to skip AAD.

Frequently asked questions:

• Q: Why doesn't my ciphertext match what my Java or Python backend produces?
  A: Check the mode, padding, key bytes, IV, charset and ciphertext format, in that order. A text key is encoded with the selected charset, while two hex characters make one byte. Even a trailing newline in the plaintext changes the output. Start with a fixed 16-byte plaintext and an all-zero IV, then introduce variables one at a time.
• Q: Decryption fails, or the first block is garbled but the rest looks fine. What's wrong?
  A: In CBC and CFB, a wrong IV only corrupts the first 16-byte block, so start there. Then check the key length, mode, padding and that you copied the full ciphertext. Base64 and hex are detected and tried automatically, so you rarely need to switch formats by hand.
• Q: What's the difference between a text key and a hex or Base64 key?
  A: A 32-character text key is 32 bytes (AES-256), but the same string read as hex is only 16 bytes (AES-128), producing completely different ciphertext. Keys must be 16, 24 or 32 bytes; invalid lengths are rejected with the actual byte count. Switching the format changes the key, so both sides must use the same one.
• Q: GCM decryption says the tag check failed. What should I do?
  A: GCM verifies an authentication tag, so a wrong key, IV, AAD or a truncated ciphertext will fail. This tool outputs IV + ciphertext + tag. Leave the IV blank to read the first 12 bytes of the ciphertext; for other IV lengths, enter it manually. If your backend stores the IV or tag separately, concatenate them in that order first. If you encrypted without AAD, leave AAD blank when decrypting.
• Q: Which charset should I use with a legacy system?
  A: UTF-8 is the default. Older Simplified Chinese systems often use GBK (2 bytes per Chinese character); use GB18030 for rare characters and emoji (up to 4 bytes), and Latin-1 for plain Western text. Plaintext always uses the selected charset, as do text-format keys and IVs, while hex and Base64 values are decoded directly. Both sides must match or you will get garbled text or different ciphertext.
• Q: Are my key and plaintext sent to a server?
  A: No. Encryption and decryption happen entirely in your browser using CryptoJS and the native WebCrypto API. The page neither sends nor stores your keys and does not write to local storage, so it is safe for checking API payloads and sensitive values in config files.
• Q: Which AES mode should I use: CBC, GCM or ECB?
  A: This tool supports ECB, CBC, CFB, CTR, OFB and GCM. For an existing system or a Java backend, match its parameters — CBC with PKCS7 (written as PKCS5Padding in Java) is the most common. For new projects, prefer GCM: it adds an authentication tag, so any change to the ciphertext or AAD fails verification. ECB needs no IV but produces identical ciphertext for identical plaintext blocks, so use it only for legacy compatibility. CFB, CTR and OFB always use NoPadding. Whatever you choose, both sides must use exactly the same settings.

Common uses:

• Verify encrypted API payloads against AES implementations in Java, PHP and Python
• Encrypt and decrypt sensitive values such as database passwords and API keys in config files
• Test client-side encrypted storage before shipping it
• Inspect ciphertext when you already have the key during security testing