CipherLayer
Home / Tools / AES-GCM

AES-GCM Encryptor

Real AES-256-GCM authenticated encryption, running in your browser via the Web Crypto API. Not a renamed XOR, not a JavaScript toy implementation — the same primitive that TLS 1.3 uses.

Authenticated AAD support Custom IV Web Crypto API Zero network

Inputs

PBKDF2-SHA256, 200,000 iterations, per-message random salt. This is the only realistic option for a browser tool — we never store keys.

AAD is bound to the ciphertext but not encrypted. Decryption requires the same AAD byte-for-byte.

Output

// Output will appear here The output is built locally. Open DevTools, watch the network tab — you will see no requests leaving your browser.
Last operation
—
Time
—
Output size
—
Heads up — derived key, not stored key. Your passphrase never leaves your browser. PBKDF2 derives a 256-bit AES key on each operation. Same passphrase + same salt = same key, which is how decryption works.

Why this tool, and why this version

Most "AES online" tools give you three modes: ECB, CBC, and "AES". Half of them default to ECB. ECB mode encrypts each 16-byte block independently, which means two identical plaintext blocks produce two identical ciphertext blocks. For any non-random plaintext — an image, an English message, a JSON document — this leaks structure. We do not offer ECB.

This tool uses GCM (Galois/Counter Mode). GCM is an AEAD — Authenticated Encryption with Associated Data. It produces a ciphertext and a 16-byte authentication tag. The tag is computed over both the ciphertext and the AAD. If either is tampered with, decryption fails and returns an error instead of returning modified plaintext. This is the difference between encryption and authenticated encryption.

The key is derived from your passphrase via PBKDF2-SHA256 with 200,000 iterations. That's the OWASP 2023 minimum for PBKDF2-SHA256. Higher is better, slower is the cost. If you have a true random 32-byte key (e.g., from our CSPRNG), skip the passphrase entirely and convert that key to hex.

The default IV is generated fresh on each encrypt. Never reuse an IV with the same key in GCM. Reuse breaks the authentication property catastrophically. This is the single most common implementation bug in real-world AES-GCM code. The tool enforces a fresh IV unless you explicitly type one.

Who this is for

Engineers integrating crypto

You need to confirm what "AES-256" actually buys you in a given mode. This tool makes the IV, salt, and tag explicit. They become inspectable. That visibility catches the bugs that real code review misses.

Students learning authenticated encryption

GCM is the default authenticated mode in TLS 1.3, SSH, and modern disk encryption. Understanding it here means understanding how half the secure web works.

Privacy-conscious individuals

Encrypt a message locally, send the ciphertext through any channel (email, chat, paper), and have the recipient decrypt it in their browser. No server sees the plaintext.

Frequently asked questions

What's the difference between AES-CBC and AES-GCM? ▶
CBC is confidentiality-only. It hides the plaintext but does not detect tampering. If an attacker flips a bit in the ciphertext, CBC will decrypt to corrupted plaintext and you may not notice. GCM adds a 16-byte tag computed over both ciphertext and AAD. Any bit flip causes tag verification to fail. For new applications, GCM (or ChaCha20-Poly1305) is the right choice. CBC should only be used inside a larger protocol that adds authentication — for example, CBC + HMAC-SHA256 in an encrypt-then-MAC construction.
Why can't I just use any 32-byte string as a key? ▶
You can — that's exactly the AES-256 key size. The tool derives a key from your passphrase because humans remember passphrases, not 32-byte hex strings. The trade-off: a passphrase is brute-forceable. "password" takes microseconds. "correct horse battery staple" takes geological time. If you have a high-entropy key from another source, paste it as a 64-hex-character string into the passphrase field and disable salt by leaving it empty (the tool will then use the raw hex).
What's AAD, and when do I need it? ▶
Additional Authenticated Data is data you want to bind to the ciphertext without encrypting it. Example: a message ID. You want the recipient to know the message ID without seeing it in plaintext, AND you want any tampering with the message ID to fail decryption. The AAD field is not in the output; the recipient must supply the same AAD at decryption time.
Can I decrypt ciphertext from another tool? ▶
Only if they use the same construction: AES-GCM, key derived via PBKDF2-SHA256 with the same iteration count and salt, IV and tag concatenated or stored separately. Switch the JSON output mode to grab the IV, salt, and tag as separate fields. Cross-tool compatibility is the cost of doing it yourself — if you want drop-in interop, OpenSSL with explicit parameters will do it.
What does the "Time" measurement tell me? ▶
It's the wall-clock time for the operation including key derivation. On modern hardware, PBKDF2 at 200k iterations takes 100-300ms. The encryption itself is sub-millisecond for typical inputs. If you see a much longer time, you probably have a very large input or a slow device. If you see a much shorter time, something is wrong — open DevTools and look at console output.
Is this safe to use for real secrets? ▶
The cryptography is real. The implementation is the Web Crypto API, used by Chrome and Firefox. The threat model you still have: your browser, your machine, your network, your screen. Malicious extensions, keyloggers, shoulder-surfing, and clipboard hijackers remain real. For casual message scrambling, this is fine. For protecting state secrets or financial keys, use a dedicated hardware token and audited libraries.

Limitations you should know