AES Encryption Playground

Encrypt and decrypt text with AES-GCM, AES-CBC, and other algorithms using the Web Crypto API.

Tested tool guide Tested browser tools Checked August 16, 2026

What AES Encryption Playground does and how it behaves

This playground lets you exercise AES encryption and decryption on text with browser Web Crypto operations, including AES-GCM and AES-CBC. You supply the cryptographic inputs needed by the chosen mode and inspect the encoded ciphertext or recovered plaintext. The frequent surprise is that plaintext alone does not determine a portable result: the exact key bytes, IV, mode, encoding, and GCM authentication settings must agree. Because encryption runs in the browser, the entered secret material is not uploaded by the tool.

How the result is produced

Text and byte conversion

AES works on bytes, not characters. The playground converts the entered text and cryptographic parameters into byte sequences, invokes the selected Web Crypto AES operation, then presents the resulting bytes in its output representation. Decryption reverses that process only when the key, mode, IV, ciphertext, and any authenticated inputs match.

Mode-specific verification

In AES-GCM, decryption also verifies an authentication tag, so a wrong key, altered ciphertext, mismatched IV, or mismatched additional authenticated data causes failure rather than yielding trusted plaintext. AES-CBC uses an IV and padding but does not authenticate the ciphertext; successful CBC decryption alone does not prove that the data was unmodified.

Good uses

Compare AES-GCM and AES-CBC behavior on the same short test message before implementing compatible application code.
Reproduce a test vector or integration fixture by entering its exact key, IV, mode, plaintext or ciphertext, and associated GCM parameters.
Demonstrate how changed ciphertext, a wrong IV, or a wrong key affects decryption, especially AES-GCM authentication failure.

Limits and checks

Ciphertext is not determined by plaintext and key alone. A changed IV normally changes the output, and a GCM IV must not be reused with the same key.
Displayed key, IV, and ciphertext values may use hexadecimal, Base64, or another representation. Compare decoded bytes, not just visible strings, when matching another system.
AES-CBC does not authenticate data. Readable plaintext, or merely a lack of a decryption error, is not an integrity check. Use an authenticated mode such as AES-GCM when tamper detection is required.

Common questions

Why does the same plaintext produce different ciphertext?

AES modes use an IV in addition to the key. If the playground uses a new IV, encrypting the same plaintext again can produce different ciphertext; that is expected. To reproduce a result, reuse the exact test parameters. Do not reuse a GCM IV with the same key in real encryption merely to force repeatable output.

Can I decrypt the result in another language?

Yes, when the other implementation receives identical key bytes, algorithm, IV, ciphertext, and applicable GCM tag length and additional authenticated data. It must also interpret encoded fields and the ciphertext-tag layout identically. No, the visible ciphertext alone is generally insufficient, and the same human-readable password does not guarantee that both sides constructed the same AES key.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.