When you visit a website with HTTPS, your browser is using AES-256-GCM. When you encrypt a file on your phone, there is a very good chance it is using AES-256-GCM. When a government agency classifies a document as Top Secret, the encryption standard they use is AES-256.
AES-256-GCM is not some niche algorithm. It is the workhorse of modern encryption. And yet most developers use it without understanding what it actually does. Let's fix that.
What AES Actually Is
AES stands for Advanced Encryption Standard. It is a block cipher, which means it encrypts data in fixed-size blocks. For AES, each block is 128 bits (16 bytes). The "256" in AES-256 refers to the key size: 256 bits.
Here is how a block cipher works at the most basic level. You provide a key and a block of plaintext. The cipher performs a series of mathematical transformations on the plaintext using the key, and outputs a block of ciphertext. To decrypt, you provide the same key and the ciphertext, and the cipher reverses the transformations to recover the plaintext.
AES itself was standardized by NIST in 2001 after a multi-year competition. It replaced DES, which had become too weak as hardware got faster. AES supports three key sizes: 128, 192, and 256 bits. All three use 128-bit blocks. The larger the key, the more rounds of transformation are applied: 10 rounds for AES-128, 12 for AES-192, and 14 for AES-256.
More rounds means more security, but also more computation. In practice, AES-256 is fast enough that the performance difference is negligible for almost all applications. And the security margin is significantly larger. This is why AES-256 is the default for anything that matters.
The Problem with Raw AES
Here is the catch: AES can only encrypt 16 bytes at a time. And if you encrypt the same 16 bytes with the same key, you get the same ciphertext every time. This means if you encrypt the word "Hello" twice with the same key, the output is identical. An attacker can see patterns.
To encrypt real data (messages, files, entire disk images), you need a mode of operation. A mode of operation defines how to break the data into blocks, how to chain them together, and how to make each block's encryption depend on something unique so patterns do not leak.
This is where GCM comes in.
What GCM Adds
GCM stands for Galois/Counter Mode. It is a mode of operation for AES that solves two problems at once.
The first problem is encryption of arbitrary-length data. GCM uses a counter: it starts with a value (derived from an IV and a counter that increments per block) and encrypts the counter itself to produce a keystream. The plaintext is then XORed with this keystream. Because the counter is different for each block, every block gets a different keystream, and patterns do not leak.
The second problem is authentication. This is the part that most people miss. Encryption alone does not guarantee integrity. An attacker who cannot read your ciphertext can still modify it. They can flip bits, truncate it, or splice parts of different messages together. Without authentication, you would have no way to detect this.
GCM solves this by computing an authentication tag. The tag is a short value (typically 128 bits) that is derived from the ciphertext and a key. When the recipient decrypts, GCM recomputes the tag and compares it to the one that was sent. If they do not match, the data has been tampered with and is rejected.
This combination of encryption and authentication is called authenticated encryption, and it is the gold standard for modern crypto. You get confidentiality (nobody can read your data) and integrity (nobody can tamper with your data without detection) in a single operation.
Why Authenticated Encryption Matters
Let me give you a concrete example of what happens without authentication. Suppose you use AES-CBC (an older mode) to encrypt a message. An attacker intercepts the ciphertext. They cannot decrypt it, but they can modify it. They flip a few bits in the ciphertext and send it on its way.
When the recipient decrypts, they get garbage in the modified blocks. But depending on the application, that garbage might be interpreted in dangerous ways. If the ciphertext is a financial transaction, the garbage might change the amount. If it is an authentication token, the garbage might change the user ID.
With GCM, this attack is impossible. The authentication tag catches the modification and the decryption fails before any garbage is processed. The recipient never sees tampered data.
This is why the cryptography community has moved to authenticated encryption as the default. It is not an optional add-on. It is a fundamental requirement for secure systems.
How the IV Works in GCM
GCM requires an initialization vector (IV), also called a nonce. The IV is a value that makes each encryption unique. Even if you encrypt the same plaintext with the same key, a different IV produces a different ciphertext.
In GCM, the IV is typically 12 bytes (96 bits). The encryption process combines the IV with a counter to produce the keystream. The authentication tag is also derived from the IV.
The critical rule is: never reuse an IV with the same key. If you reuse an IV, an attacker can XOR two ciphertexts together and the keystreams cancel out, leaving you with the XOR of the two plaintexts. This is called a two-time pad and it is devastating. For GCM specifically, IV reuse is even worse because it allows the attacker to recover the authentication key and forge tags.
The good news is that generating a random 12-byte IV is trivial, and the Web Crypto API does it for you automatically. You can try this yourself with our AES text encryptor, which generates a fresh IV for every encryption.
How the Web Crypto API Implements It
Every modern browser ships with the Web Crypto API, which provides native AES-256-GCM support. Here is the basic flow:
1. Generate a 256-bit key using crypto.subtle.generateKey. 2. Generate a 12-byte IV using crypto.getRandomValues. 3. Encrypt using crypto.subtle.encrypt with the AES-GCM algorithm, the key, the IV, and the plaintext. 4. The output is the ciphertext plus the authentication tag (GCM appends the tag to the ciphertext). 5. To decrypt, use crypto.subtle.decrypt with the same key and IV. If the tag does not match, decryption fails.
The IV is not secret. It needs to be stored or transmitted alongside the ciphertext so the recipient can use it for decryption. The key, obviously, must be kept secret.
If you are deriving the key from a password (which is the common case for user-facing tools), you use a key derivation function like PBKDF2 to turn the password into a 256-bit key. This adds computational cost, which slows down password guessing attacks. We cover this in more detail in our PBKDF2 vs bcrypt vs Argon2 comparison.
Why This Is the Default
AES-256-GCM is the default for a simple reason: it is the combination of a cipher (AES-256) that has been studied for over 20 years with no practical attacks found, and a mode (GCM) that provides both encryption and authentication in a single, efficient operation. It is fast (especially with hardware acceleration), it is well-supported, and it is secure when used correctly.
If you are building something that needs encryption and you are not sure what to use, AES-256-GCM is almost always the right answer. The main thing to get right is the IV: generate a fresh random one for every encryption and never reuse it. For a deeper dive on that topic, read our post on what an IV is and why reuse is dangerous.
You can see AES-256-GCM in action right now with our AES text encryptor. Encrypt a message, change one character, and watch how the entire ciphertext changes. That is the IV doing its job.
