A secret message.
The same key.

You type Hello Shea. The browser uses UTF-8 to turn the characters into bytes. This message contains 10 bytes: five letters, a space, and four more letters.

48 65 6c 6c 6f 20 53 68 65 61

Those hexadecimal values are another representation of the readable message. Each pair represents one byte. Anyone can convert them back without a secret key. Encoding is not encryption. Accented characters and emoji can occupy more than one UTF-8 byte, so character count and byte count are not always equal.

Try it: enter Hello Shea in the Plaintext box before encrypting.

Click Generate 256-bit key. The browser creates 32 random bytes using its cryptographic random generator. Since each byte contains eight bits, 32 × 8 = 256 bits.

The page displays the key as 64 hexadecimal characters. Two hex characters represent one byte, so 64 hex characters describe 32 bytes, not 64 bytes.

The key selects the AES transformation. Someone who obtains both the key and encrypted package can decrypt the text. In a real system, keep the key separately under controlled access. It is visible here for learning.

An ordinary word such as classroom is not a raw AES-256 key. Turning a password into a key needs a separate password-based key derivation design.

When you click Encrypt message, the lab also generates a random 12-byte IV: 12 × 8 = 96 bits, displayed as 24 hex characters. You do not need to type it yourself.

IV means initialisation vector. Nonce means a number used once. The terms emphasise different properties. Requirements depend on the encryption mode. In AES-GCM, the IV acts as a nonce and must never repeat with the same key.

The IV is not another password and does not need to be secret. It goes with the ciphertext. You may keep the same key across messages within an appropriate key policy, but each new encryption needs a fresh nonce.

Random values can collide. Random 96-bit IVs suit this small classroom demonstration, while production systems need a documented uniqueness strategy and per-key usage limits.

Try it: keep the key unchanged, encrypt twice, and compare the two IV fields.

GCM uses the IV to establish counter values. AES encrypts these counter values using the secret key, producing masking bytes called a keystream. The tool combines the keystream and plaintext using XOR.

Plaintext XOR Keystream = Ciphertext

XOR is a binary operation. Applying the same keystream again reverses this combination:

Ciphertext XOR Keystream = Plaintext

For Hello Shea, the ciphertext contains 10 bytes, just like the UTF-8 plaintext. Its hex representation therefore contains 20 characters. GCM does not require padding to a whole AES block.

GCM uses AES encryption on counter blocks during both encryption and decryption. It does not simply run the raw AES inverse cipher over each ciphertext block. Read the GCM specification.

Hiding the text does not, by itself, establish whether somebody changed it. GCM also calculates an authentication tag using the secret key and authenticated inputs. The lab uses a 16-byte, or 128-bit, tag.

During decryption, the receiver verifies the tag against the supplied inputs. A changed ciphertext, wrong key, altered tag or incorrect IV should cause verification to fail. The error does not identify which input was wrong.

GCM can also authenticate visible metadata, called associated authenticated data (AAD). A record identifier is one example. AAD stays readable but must match exactly at both ends. This simple lab does not use AAD.

A tag provides authentication under the shared key. It does not prove which individual key holder sent the message, and it does not by itself prevent replay.

The package contains the algorithm and version, IV, ciphertext and tag. It contains neither the secret key nor the original plaintext. For our Hello Shea example:

These sizes describe the binary values, not the whole JSON package. Labels, quotes and hexadecimal encoding make the displayed package longer. The receiver needs the original key and complete package, with the agreed algorithm and format.

Try it: find iv, ciphertext and tag in Encrypted package. Notice that there is no key field.

Click Send package to decryption, then Use key from step 1, then Decrypt message.

1. The tool reads the IV, ciphertext and tag.
2. The original key and IV reproduce the required keystream.
3. The ciphertext and keystream recover the plaintext bytes.
4. The browser verifies the authentication tag.
5. The page displays the recovered text only after successful verification.

The result should be Hello Shea. The receiver does not need to supply the original plaintext. The lab clears earlier recovered text when inputs change or a new decryption attempt fails, so an old result cannot look like a new success.

Encrypt Hello Shea again without changing the key. The lab generates another IV. That changes the counter sequence and keystream, so the ciphertext changes and the tag normally changes too.

Both original packages still decrypt with the same key, as long as each retains its own IV and tag. A different result does not imply the key changed.

Try it: note the first IV before encrypting again. Do not click Generate 256-bit key between the two attempts.

Repeating an AES-GCM key and IV repeats the encryption keystream. With two different messages, an attacker can combine their ciphertexts to expose a relationship between the plaintexts. If one message is known, this can help reveal the other. Nonce reuse can also undermine authentication.

Keep the key secret. Keep the IV with the encrypted message. Never reuse an IV with the same AES-GCM key.

A successful library call does not prove safe nonce handling. This lab creates IVs automatically rather than offering a manual reuse option. Different modes have different IV rules: for example, CBC requires an unpredictable IV and does not supply GCM’s built-in authentication.

AES arranges a 16-byte input block in a four-by-four state, filling columns. A key schedule derives round keys from the secret key. After an initial AddRoundKey, ordinary encryption rounds apply these operations:

SubBytes

Replaces each byte using an invertible nonlinear substitution.

ShiftRows

Rotates rows so bytes move between columns.

MixColumns

Combines bytes within each column using finite-field arithmetic.

AddRoundKey

XORs the round key into the state.

The final round omits MixColumns. The AES inverse cipher uses inverse transformations for raw block decryption. In this lab’s GCM mode, the encrypted counter blocks generate the keystream in both directions.

FIPS 197 defines AES and its round structure.

Joan Daemen and Vincent Rijmen designed Rijndael. NIST selected it in 2000 after an open competition, and AES became FIPS 197 in 2001. The 2023 editorial update improved the presentation without changing the algorithm.

AES fixes the block size at 128 bits. The original Rijndael family allowed additional block sizes. A longer AES key adds rounds and increases the key-search space, but it does not enlarge the block or fix poor key storage.

Explore NIST’s AES development history.

No. The key must stay secret. The IV normally travels openly with ciphertext. The receiver needs both, but they have different security requirements. AES-GCM requires nonce uniqueness under the key.

The earlier package still needs its original key. A newly generated key cannot recover it. Restore the original key, or encrypt a new package with the new key. Losing the only usable key makes the encrypted data unavailable.

This tool uses authenticated encryption and releases text only after verification. A wrong key fails that check. A failed tag can also mean damaged data, a wrong IV or another mismatched input. The error alone does not identify the cause.

No. An old, unchanged encrypted message can still have a valid tag. A real application may need sequence numbers, expiry checks or record state to reject a replay. It also needs access control to decide who may decrypt.

Use disposable generated keys and invented messages. A password needs a suitable key derivation process before use as an AES key. Real systems should manage keys through controlled custody and secure exchange. This page intentionally exposes key values for teaching.

HTTPS uses TLS, which combines encryption with a larger protocol for establishing keys and authenticating peers. TLS can use AES-GCM. Disk encryption often uses AES-XTS, which serves a different storage purpose and does not authenticate messages like GCM. An AES label alone does not describe the whole security design.