How AES Encryption Works (Without the Math)

AES is the cipher behind your HTTPS traffic, your encrypted disk, your password manager, and almost every "encrypted" checkbox in modern software. Most explanations of it detour immediately into finite field arithmetic over GF(2^8), which is accurate and completely unhelpful if what you want is a working mental model. This walks through what AES actually does to your data, and — more importantly — which of its knobs you have to set correctly.

If you are still deciding whether encryption is even the right transformation for your problem, start with Encryption vs Encoding vs Hashing: The Complete Guide, which lays out when to encrypt, when to encode, and when to hash instead.

AES Is a Symmetric Block Cipher

Two words carry all the weight there.

Symmetric means the same key encrypts and decrypts. There is no public key and no private key — one secret, shared by everyone who is allowed to read the data. That makes AES extremely fast and completely dependent on you solving the problem of getting the key to the other party safely.

Block cipher means AES does not process a stream of arbitrary length. It operates on fixed 128-bit blocks — exactly 16 bytes — regardless of key size. This is the single most misunderstood fact about AES: the block size is always 128 bits. AES-256 refers to a 256-bit key, not a 256-bit block. The three standard variants are AES-128, AES-192, and AES-256, all chewing through the same 16-byte blocks.

Since real data is rarely a neat multiple of 16 bytes, and since encrypting each block independently would leak patterns, a mode of operation wraps the raw cipher to handle both problems. Choosing that mode correctly matters more than choosing between 128- and 256-bit keys.

What Happens Inside a Block

AES treats each 16-byte block as a 4×4 grid of bytes called the state, then scrambles it through a series of rounds — 10 rounds for AES-128, 12 for AES-192, and 14 for AES-256. Each round applies four operations:

1. SubBytes — every byte is replaced using a fixed lookup table (the S-box). This is the non-linear step, and it is what stops the whole cipher from being solvable as a system of linear equations.
2. ShiftRows — each row of the grid is rotated left by a different amount. Bytes now influence different columns than they started in.
3. MixColumns — each column is combined so that changing one input byte changes all four output bytes in that column. Together with ShiftRows, this spreads a single-bit change across the entire block within a couple of rounds.
4. AddRoundKey — the state is XORed with a round key derived from your main key by the key schedule.

That is the entire cipher: substitute, shift, mix, XOR with key material, repeat. The design goal is confusion (the relationship between key and ciphertext is complex) and diffusion (one changed input bit affects roughly half the output bits). More rounds for larger keys is why AES-256 is around 40% slower than AES-128 — fourteen rounds versus ten.

You do not need to implement any of this. You do need to set the parameters around it correctly, and that is where systems actually break.

The Three Settings That Actually Matter

1. Mode: Use GCM

AES-GCM (Galois/Counter Mode) is authenticated encryption. It produces ciphertext plus a 16-byte authentication tag. On decryption, if even one bit of the ciphertext, IV, or associated data was modified, the tag check fails and decryption returns an error instead of garbage. You get confidentiality and integrity from one primitive.

AES-CBC (Cipher Block Chaining) provides confidentiality only. Ciphertext can be modified by an attacker and CBC will happily decrypt it into altered plaintext with no complaint. Making CBC safe requires computing a MAC such as HMAC-SHA-256 over the ciphertext and verifying it before decrypting — the encrypt-then-MAC construction. It works, but it is an extra step that has been implemented backwards in production systems many times, producing padding oracle vulnerabilities.

ECB mode should never be used. It encrypts each block independently, so identical plaintext blocks produce identical ciphertext blocks, and the structure of the original data remains visible in the output.

The short version: choose AES-256-GCM unless a protocol you must interoperate with forces something else.

2. IV: Fresh and Random Every Time

The initialization vector ensures that encrypting the same plaintext twice with the same key produces different ciphertext. For GCM the IV is 12 bytes, it does not need to be secret, and it is normally stored right in front of the ciphertext.

What it absolutely must be is unique per encryption under a given key. IV reuse in GCM is not a minor weakness — it lets an attacker recover the XOR of two plaintexts and, worse, derive the authentication subkey and forge valid tags. Generate the IV from a cryptographically secure source such as the Cryptographic Random Bytes Generator, never from a counter you might reset or a timestamp.

3. Key: Derived, Not Typed

An AES-256 key is 32 bytes of full-entropy randomness. A password is neither 32 bytes nor full entropy. Feeding a password in directly — padded or truncated to fit — throws away most of AES's strength, because the attacker only has to guess your password, not your key.

Use a key derivation function. PBKDF2 with a random 16-byte salt and a high iteration count is the widely supported option, and the PBKDF2 Key Derivation Generator shows how salt and iteration count change the derived key. Argon2id is the stronger modern choice where available, because it is memory-hard and therefore far more expensive to attack with GPUs. Store the salt with the ciphertext; it is not secret either.

Putting It Together

A correctly encrypted payload contains four things, and only one of them is secret:

[ salt (16 bytes) ][ IV (12 bytes) ][ ciphertext ][ auth tag (16 bytes) ]

The key itself is never stored with the payload — it is derived from the password plus salt at decryption time. Everything else travels in the open, which is why this whole blob is commonly Base64 encoded afterwards to survive JSON, headers, or email. That encoding step adds no security whatsoever; it is a transport wrapper on top of the real protection.

You can watch all of this happen with the AES Encryption & Decryption tool. Encrypt the same text twice with the same password and you will get two different outputs — that is the IV doing its job. Change a single character of the ciphertext and decryption fails outright rather than producing corrupted text — that is the GCM authentication tag doing its job. Everything runs in your browser through the Web Crypto API, so the plaintext and password never leave your device.

Where AES Fits

AES is fast because it is symmetric, and it is symmetric because both sides use the same key. That leaves the awkward question of how a key reaches someone you have never shared a secret with. The answer is that AES does not solve that problem — asymmetric cryptography does, by encrypting or negotiating the AES key itself. Symmetric vs Asymmetric Encryption Explained covers how the two are combined in TLS, and RSA Key Pairs: What They Are and How to Generate Them covers the key-wrapping side in detail.

Conclusion

AES has not been broken and almost certainly will not be. Every real-world AES failure has come from the parameters around it: an IV reused, a password used raw as a key, CBC deployed without authentication, or a key committed to a repository. Pick AES-256-GCM, generate a fresh random IV per message, derive the key from a password with PBKDF2 or Argon2, and store salt and IV alongside the ciphertext. Get those four things right and the cipher itself will never be your weak point.