AES Encrypter & Decrypter
Enter text + password → Click Encrypt/Decrypt → Copy result. AES-256-GCM, entirely in your browser.
GCM vs CBC vs CTR — pros and cons
| Mode | Authentication | IV | Parallel |
|---|---|---|---|
| GCM | Built-in | 12 bytes | Yes |
| CBC | None (add HMAC) | 16 bytes | Decrypt only |
| CTR | None (add HMAC) | 16 bytes (nonce) | Yes |
AES-256-GCM encryption in popular languages
Key management, IV handling, and common pitfalls
Minimum 12 characters with uppercase, lowercase, digits, and symbols. Password strength directly determines encryption security.
Each encryption must use a unique initialization vector (IV). Reusing an IV with the same key completely breaks GCM security.
Never use a password directly as an AES key. Derive keys using PBKDF2 (100k+ iterations) or Argon2id for resistance to brute-force.
GCM provides authentication automatically. With CBC/CTR, always add HMAC-SHA256 to detect tampering.
Never store keys in source code or environment variables in plain text. Use a key management service (AWS KMS, GCP KMS, HashiCorp Vault).
Set key rotation schedules. Re-encrypt data with new keys. Keep old keys accessible for decryption during transition.
What is AES Encryption?
AES (Advanced Encryption Standard) is a symmetric encryption algorithm selected by the U.S. National Institute of Standards and Technology (NIST) as the federal encryption standard in 2001, replacing the aging DES (Data Encryption Standard). AES was designed by Belgian cryptographers Joan Daemen and Vincent Rijmen, originally named the Rijndael algorithm.
AES operates on 128-bit data blocks and supports three key sizes: 128, 192, and 256 bits. AES-256 is considered secure enough for top-secret classified data according to NSA guidelines. Today, AES is used everywhere: WiFi security (WPA2/WPA3), full-disk encryption (BitLocker, FileVault), TLS/HTTPS protocol, VPNs, end-to-end encrypted messaging (Signal, WhatsApp), and millions of other systems worldwide.
How AES-256-GCM Works
GCM (Galois/Counter Mode) is the most modern AES mode of operation, combining both encryption and authentication in a single step — known as AEAD (Authenticated Encryption with Associated Data). This means GCM not only keeps your data secret but also ensures it has not been tampered with during transmission.
The encryption process in this tool:
- Step 1 — Generate random salt: 16 bytes of salt are created using
crypto.getRandomValues(). The salt ensures the same password produces different keys each time you encrypt. - Step 2 — Key derivation (PBKDF2): Your password is transformed into a 256-bit AES key through PBKDF2 with 100,000 iterations of SHA-256. This process is intentionally slow to resist brute-force attacks.
- Step 3 — Generate IV: 12 random bytes of IV (Initialization Vector) are created. The IV ensures the same plaintext and key produce different ciphertext every time.
- Step 4 — AES-GCM encryption: The Web Crypto API performs AES-256-GCM encryption, producing ciphertext with a 128-bit authentication tag.
- Step 5 — Packaging: Salt + IV + ciphertext (including auth tag) are concatenated and Base64-encoded for easy sharing as text.
AES vs Other Encryption Algorithms
| Algorithm | Type | Key size | Speed | Status |
|---|---|---|---|---|
AES-256 | Symmetric | 256-bit | Very fast | Current standard |
ChaCha20 | Symmetric | 256-bit | Fast (mobile) | Modern alternative |
3DES | Symmetric | 168-bit | Slow | Deprecated |
RSA | Asymmetric | 2048-4096 bit | Very slow | Used for key exchange |
Blowfish | Symmetric | 32-448 bit | Medium | Legacy, bcrypt only |
AES-256 remains the top choice for symmetric encryption thanks to its balance of security, performance, and widespread hardware support (AES-NI instruction set). ChaCha20-Poly1305 is a good alternative on mobile devices without AES-NI hardware acceleration.
Common Mistakes in Encryption
- Reusing IVs/nonces: This is the most critical error with AES-GCM. Using the same IV with the same key twice allows an attacker to XOR the two ciphertexts to reveal plaintext, and completely breaks the authentication tag.
- Using passwords directly as keys: Passwords are typically too short and have low entropy. Always use a key derivation function (PBKDF2, Argon2, scrypt) to transform passwords into secure keys.
- Not authenticating ciphertext: With CBC or CTR mode, without a MAC (Message Authentication Code), attackers can modify ciphertext undetected (padding oracle attacks). GCM solves this with built-in authentication.
- Hardcoding keys in source code: Embedding encryption keys in your codebase is a common security mistake. Use environment variables or a key management service (AWS KMS, GCP KMS, HashiCorp Vault).
- Confusing encoding with encryption: Base64, URL encoding, and hex are NOT encryption. They are data representation methods that anyone can decode instantly. For security, you need real cryptographic algorithms like AES.
- Never rotating keys: Using the same key indefinitely increases risk if the key is compromised. Establish key rotation schedules and re-encrypt data periodically with fresh keys.
Using AES Encryption in Your Code
Most modern programming languages provide built-in or readily available AES encryption libraries. The most important principle: never implement cryptographic algorithms yourself — always use audited, battle-tested libraries.
In the browser, the Web Crypto API (crypto.subtle) provides AES-GCM with native performance. In Node.js, the built-in crypto module fully supports AES. Python has the cryptography library (pyca/cryptography) — the best choice for production use. Go has the crypto/aes and crypto/cipher packages in its standard library.
This tool uses the Web Crypto API exclusively — your data never leaves the browser. See the Code Snippets card above for copy-paste ready examples in JavaScript, Python, and Node.js for both encryption and decryption operations.
About Developer Tools
Developer tools automate the repetitive parts of software work: formatting JSON, encoding/decoding Base64, decoding JWTs to verify token claims, generating UUIDs, formatting XML, diffing configurations. These aren't glamorous tasks, but they're the friction points that eat 10-15 minutes multiple times a day — adding up to hours weekly. Running them in a clean browser tab beats wrestling with CLI dependencies or IDE extensions that might ship your private data to a third party.
Why it matters
Fast, client-side developer tools fundamentally matter because they're used with sensitive data. JWT tokens contain user identity. Base64 payloads might encode API keys. JSON dumps include customer records. If a 'developer tool' sends your input to a server to process, you've just leaked production secrets. ZestLab's dev tools run 100% client-side with no network calls after page load — what you paste stays in your browser.
Privacy and safety
All developer tools here execute in-browser using pure JavaScript. There's no 'decode server' or 'format API' — your JWT, your JSON, your encoded payload is parsed by code running on your laptop. Verify this yourself with browser DevTools → Network tab: you'll see zero outbound requests when using any tool. That's a standard we hold because dev tools handle secrets.
Best practices
- Never paste production JWT or API tokens into ANY online tool without verifying it runs client-side (check the Network tab)
- Use browser private/incognito mode for one-off decoding of sensitive payloads
- Bookmark tools you use daily — ZestLab tool URLs are stable and don't require accounts
- When formatting JSON with secrets for team review, redact credentials before sharing the formatted output