How to Encrypt and Decrypt Text Using AES-256-GCM in Your Browser
Encryption used to mean installing OpenSSL, writing shell scripts, or trusting third-party services with your data. Today, modern browsers expose the Web Crypto API — a low-level, native cryptography interface built right into Chrome, Firefox, Safari, and Edge. With it, you can perform genuine AES-256-GCM encryption without any libraries, without any server, and without surrendering your plaintext to anyone. This guide explains exactly how that works and how to use the tool above effectively.
What AES-256-GCM Actually Means
AES (Advanced Encryption Standard) is the symmetric cipher used by governments, banks, and security agencies worldwide. The 256 refers to the key length in bits — a 256-bit key has 2^256 possible values, an astronomically large number that makes brute-force attacks computationally impossible with any foreseeable technology.
GCM stands for Galois/Counter Mode. This is where AES-256-GCM becomes genuinely superior to older modes like AES-CBC. GCM is an authenticated encryption mode, which means it does two things simultaneously: it encrypts your data (confidentiality) and it generates an authentication tag that detects any tampering with the ciphertext (integrity). If someone flips a single bit in your encrypted data and you try to decrypt it, GCM will reject it with an authentication failure rather than silently giving you corrupted output. This property is called AEAD — Authenticated Encryption with Associated Data — and it is the gold standard for symmetric encryption.
The Role of PBKDF2 Key Derivation
Human-chosen passphrases are weak. They have patterns, limited character sets, and are nowhere near 256 bits of entropy. You cannot feed a passphrase directly into AES-256 — you need a key derivation function (KDF) to transform it into a proper cryptographic key.
This tool uses PBKDF2 (Password-Based Key Derivation Function 2) with SHA-256 as the underlying hash. PBKDF2 works by running the passphrase and a random salt through the hash function thousands of times (the iteration count). Each additional iteration makes the derivation slightly slower. The goal is deliberate: a legitimate user deriving a key once will not notice 250,000 iterations taking a fraction of a second, but an attacker trying billions of passphrases per second will be throttled to a tiny fraction of that speed. At 250,000 iterations, even GPUs capable of billions of SHA-256 hashes per second are limited to perhaps tens of thousands of passphrase guesses per second — a massive defensive advantage.
The random salt is equally important. It is 16 bytes (128 bits) of cryptographically random data generated fresh for every single encryption operation. Even if two people encrypt the same text with the same passphrase, they will produce completely different ciphertexts because the salt — and thus the derived key — will differ. This defeats precomputed rainbow table attacks entirely.
Understanding the Output Format
When you click Encrypt, the tool produces a Base64-encoded string. Under the hood, this string encodes a concatenation of several components in a fixed layout:
- Bytes 0–15 (16 bytes): The random PBKDF2 salt
- Bytes 16–27 (12 bytes): The random AES-GCM initialization vector (IV)
- Bytes 28 onward: The AES-GCM ciphertext with the 16-byte authentication tag appended (the Web Crypto API appends the tag automatically)
This self-contained format means the ciphertext carries everything needed to decrypt itself — except the passphrase and the iteration count. When you paste it back into the tool and click Decrypt, the tool reads the salt from bytes 0–15, re-derives the key using your passphrase and those same bytes, reads the IV from bytes 16–27, then asks the AES-GCM cipher to authenticate and decrypt the remaining bytes. If the passphrase is wrong or the data has been modified, the authentication tag check fails and decryption is refused.
Choosing the Right Iteration Count
The PBKDF2 iteration count is a trade-off you control. The tool offers four options:
100,000 iterations is the minimum recommended by NIST for PBKDF2-SHA-256. It is fast enough to be imperceptible on any modern device and is perfectly acceptable for most use cases.
250,000 iterations is the default selection and strikes a practical balance. Encryption takes roughly 200–400 milliseconds on a modern laptop — noticeable but not annoying — while making brute-force attacks significantly harder than the minimum.
500,000 and 1,000,000 iterations are for high-security scenarios where the passphrase might be shorter or where you are protecting something that must stay secret for years. On mobile devices, these options may take 1–3 seconds, which is worth it for the security gain.
One important operational note: you must use the same iteration count to decrypt as you used to encrypt. The iteration count is not stored in the ciphertext — it is a parameter you must remember alongside your passphrase. If you encrypt with 500,000 iterations and later try to decrypt with 250,000, the derived key will be different and decryption will fail. A practical convention is to always use 250,000 unless you have a specific reason to go higher, so you never have to think about it.
Passphrase Best Practices
PBKDF2 slows down attackers, but a weak passphrase is still a weak passphrase. A passphrase like "password123" will be cracked regardless of iteration count because it will be near the top of every wordlist an attacker tries. For genuinely secure encryption:
Use at least four random words from a large vocabulary (a diceware-style passphrase), or use a password manager to generate a random high-entropy string. The passphrase "correct horse battery staple" is infinitely stronger than "Password1!" because of its length and true randomness. Length beats complexity every time with modern hashing algorithms.
Never reuse passphrases across different encrypted payloads if those payloads will live in different places. If one environment is compromised and someone learns the passphrase, the others are exposed.
What This Tool Cannot Protect Against
Client-side encryption is powerful but not magical. The tool cannot protect you from malware running on your own machine that reads clipboard contents or keystrokes before encryption happens. It cannot protect you from a browser extension that injects script into the page. It cannot protect the passphrase itself — if someone learns your passphrase through phishing, shoulder surfing, or a data breach on a site where you reused it, the encryption provides no protection.
AES-256-GCM is also a symmetric cipher, meaning the same key encrypts and decrypts. You cannot share the ciphertext with someone without also sharing the passphrase through a separate, secure channel. For asymmetric use cases — where you want to encrypt something for someone who can decrypt it without you ever knowing their private key — you would need a different system such as PGP or NaCl box encryption.
Use this tool for what it is excellent at: encrypting sensitive text for your own storage, sharing secrets over insecure channels where both parties already know the passphrase, and learning how modern authenticated encryption actually works in practice.