AES-GCM basics (nonce, tag, AAD)

AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) is the default authenticated encryption mode in modern browsers, TLS, and many APIs. It does two jobs at once: confidentiality (ciphertext hides the plaintext) and integrity (a short tag detects tampering). That combination is called AEAD — authenticated encryption with associated data.

This guide explains the pieces you paste into tools (key, IV/nonce, optional AAD, ciphertext+tag), the rules that break decryption when violated, and why encrypting locally with Web Crypto keeps keys and plaintext off servers.

The pieces of an AES-GCM message

Piece	Role	Typical size
Key	Secret AES key	128, 192, or 256 bits
IV / nonce	Unique value per encryption under that key	96 bits (12 bytes) is the interoperable default
Plaintext	Bytes you want to hide	Any length (practical limits apply)
AAD (optional)	Data that is authenticated but not encrypted	e.g. headers, routing metadata
Ciphertext	Encrypted payload	Same length as plaintext
Tag	Authentication tag	Usually 128 bits (16 bytes)

In many APIs (including the Web Crypto encrypt / decrypt surface and LocalTools’ tool), the tag is appended to the ciphertext. When you paste “ciphertext,” you are usually pasting ciphertext ‖ tag, not ciphertext alone.

Why GCM needs a unique nonce

GCM turns AES into a stream-like construction driven by a nonce (also called an IV). The rule is absolute:

Never encrypt two different messages with the same key and the same nonce.

If you reuse a nonce under one key, an attacker who sees both ciphertexts can often recover plaintext XOR relationships and, in worst cases, forge tags. Generating a fresh 12-byte nonce from a CSPRNG for every message is the safe default. Counters work too if you can guarantee uniqueness for the lifetime of the key.

Web Crypto and LocalTools’ AES-GCM Encrypt & Decrypt tool expect a 96-bit (24 hex character) IV for interoperability. Longer or shorter IVs exist in the GCM spec, but 12 bytes is what most stacks assume.

The authentication tag

After encryption, GCM produces a tag (commonly 128 bits). On decrypt, the library recomputes the tag from ciphertext, key, nonce, and AAD. If anything was altered—or if the wrong key/IV/AAD was supplied—decrypt fails instead of returning garbage plaintext.

That failure mode is a feature. Prefer APIs that refuse to return plaintext on tag mismatch (Web Crypto’s decrypt does this).

Symptom	Likely cause
Decrypt always fails	Wrong key, wrong IV, wrong AAD, truncated bytes, or Base64/hex encoding mismatch
Decrypt works once, fails after edit	Tag caught tampering (good)
“Works” with wrong AAD	You are not using AEAD correctly—or AAD was empty on both sides

AAD: authenticated but not encrypted

Additional authenticated data (AAD) is optional input that GCM includes in the tag calculation without encrypting it. Use it for context that must stay readable but must not be swapped:

• Protocol version or message type headers
• Sender / recipient identifiers in a cleartext envelope
• Non-secret metadata that must bind to this ciphertext

Both sides must supply identical AAD bytes. If encrypt used AAD and decrypt omits it (or changes one byte), the tag check fails. If neither side uses AAD, leave it empty—do not invent mismatched placeholders.

AAD is not a substitute for encrypting secrets. Anything in AAD is visible to anyone who sees the message.

Key sizes and hex pasting

AES keys are 16, 24, or 32 bytes (128 / 192 / 256 bits). Tools often show them as hex:

Bits	Hex length
128	32 characters
192	48 characters
256	64 characters

Prefer 256-bit keys when you control the format. Generate keys with a CSPRNG (crypto.getRandomValues), not Math.random(). Treat the key like a password: never commit production keys, and prefer local generation over pasting into untrusted sites.

Encoding: Base64, hex, and the trailing tag

Ciphertext+tag is binary. For copy/paste, convert to Base64 or hex—and use the same encoding on decrypt. A common failure mode is encrypting as Base64, then pasting into a hex decoder (or truncating the last 16 bytes of tag).

Raw file modes usually mean: write or read ciphertext concatenated with the 128-bit tag, with no Base64 wrapping.

Encrypt and decrypt locally

Online “AES encrypt” pages that upload your key and plaintext create an unnecessary trust surface. Prefer:

1. Web Crypto AES-GCM in the browser (or a known-good CLI).
2. Fresh random IV per message; never reuse with the same key.
3. Matching AAD and encoding on both sides.

LocalTools’ AES-GCM Encrypt & Decrypt runs entirely in-tab: paste or generate a hex key and 12-byte IV, optional hex AAD, encrypt or decrypt text or files, and copy Base64 or hex ciphertext that includes the tag. Keys and plaintext never leave the device.

Common pitfalls

• IV reuse under one key — catastrophic for GCM; always generate a new IV.
• Forgetting the tag — truncated ciphertext fails authentication.
• AAD mismatch — empty vs non-empty, or different hex, looks like a “wrong key” error.
• Encoding mismatch — Base64 vs hex, or spaces/0x prefixes handled inconsistently.
• Using AES-GCM for passwords alone — encrypting does not replace hashing for password storage; use a KDF/password hash for that job.

Try it in the browser

Use AES-GCM Encrypt & Decrypt to:

1. Generate a 128/192/256-bit key and a fresh 12-byte IV.
2. Encrypt a short UTF-8 string (optionally with AAD), copy Base64 or hex output.
3. Decrypt with the same key, IV, AAD, and encoding — then change one AAD byte and confirm the tag check fails.

Related reading: Why “local only” matters for developer tools for the privacy model, Generating passwords and tokens in the browser for CSPRNG key material, and What is TOTP? for another local-first crypto workflow that depends on shared secrets staying private.