AES Compatibility and Learning Tool

Compare AES results by matching the full parameter set

This AES encrypt/decrypt page is suited to learning and compatibility checks with test data. It accepts UTF-8 text to encrypt and shows the ciphertext as both Base64 and Hex. For decryption, choose whether the pasted ciphertext is Base64 or Hex; the result includes readable text plus Base64 and Hex views of the decrypted bytes. These encodings are ways to write bytes as text. They do not change the encryption.

AES is a symmetric block cipher: the same secret key is used to encrypt and decrypt. NIST defines AES-128, AES-192, and AES-256. The number names the key length, while every AES version processes 128-bit (16-byte) blocks. A match therefore depends on more than choosing “AES”: the key bytes, mode, padding, IV and ciphertext encoding must also agree.

Key formats describe bytes, not labels

The key can be interpreted as UTF-8 text, Hex, or Base64. The chosen AES size must match the decoded key length: AES-128 takes 16 bytes, AES-192 takes 24, and AES-256 takes 32. In Hex, that is 32, 48, or 64 valid hexadecimal characters. For text keys, count the UTF-8 bytes rather than visible characters; a non-ASCII character can occupy more than one byte. Base64 is decoded before its byte length is checked. The page does not derive a key from a password, so a short passphrase is not automatically expanded into a valid AES key.

The available AES modes are ECB, CBC, CFB, OFB, and CTR; the available padding choices are PKCS7, Zero Padding, No Padding, ISO 10126, and ANSI X.923. They are separate settings and both sides of a compatibility check need the same selection. The NIST descriptions of these five modes are in SP 800-38A; AES key and block sizes are specified by FIPS 197.

Run a repeatable compatibility check

1. Copy the peer system's settings

   Confirm the AES key size, key representation, mode, padding, IV representation, and ciphertext encoding from the protocol or test fixture. “AES-256” alone does not specify a complete recipe.

2. Enter the exact key bytes

   Choose Text, Hex, or Base64 to match how the key is supplied. Check the resulting byte count against the selected AES size. For a repeatable test, use a dedicated test key rather than a production secret.

3. Set the IV when the mode uses one

   ECB has no IV. CBC, CFB, OFB, and CTR show an IV input. AES uses a 16-byte block, so a manually supplied IV or initial counter block must represent 16 bytes: 32 Hex characters or Base64 that decodes to 16 bytes. The form offers Hex and Base64 but does not validate this length; confirm it yourself against the protocol. If encryption generates an IV automatically, record the displayed value separately.

4. Encrypt or decrypt and compare bytes

   Encryption takes UTF-8 text and returns Base64 and Hex ciphertext. Decryption takes ciphertext in the selected Base64 or Hex format and returns text and both byte encodings. Compare the Hex bytes with the other implementation when diagnosing formatting differences, and keep the mode, padding, key, and IV unchanged for the reverse check.

Padding controls how data is fitted to a mode's requirements; it is not another encryption layer. No Padding requires the input length to meet the selected mode's rules. For CBC with AES, that means complete 16-byte blocks. Never assume another application's default padding or ciphertext wrapper matches this page.

Common causes of mismatched results

Use this page for comparison, not as a production encryption system

The supported list does not include GCM or another authenticated mode, and these outputs contain no authentication tag. The page is intended for learning and compatibility checks, not as a complete production data-protection design.

• ECB reveals repeated-block patterns and should not be used for ordinary sensitive data. CBC, CFB, OFB, and CTR provide confidentiality modes but do not authenticate a ciphertext. OWASP's current guidance prefers authenticated encryption where available and calls for separate authentication when CBC or CTR must be used.
• Use non-sensitive test values. Keep any real key private and separate from ciphertext; anyone with the key and matching parameters can decrypt it. Do not paste production secrets or sensitive personal data into a general-purpose page.
• Keep the IV or initial counter value with the ciphertext as required by the chosen protocol, but do not treat it as part of the displayed ciphertext: this page returns ciphertext bytes separately. Follow the protocol's uniqueness or unpredictability rules for IVs and never substitute a fixed IV for a production design.