AES Encryption
AES-GCM encryption and decryption via WebCrypto with key and IV input, supporting base64 or hex for both text and ciphertext — sensitive data never leaves the browser.
>_ USAGE GUIDE
Encrypt and decrypt AES locally using the browser's built-in WebCrypto, in GCM (authenticated, recommended) or CBC (PKCS#7, for legacy integrations). Keys come either raw (hex / base64, 16 / 24 / 32 bytes) or derived from a passphrase via PBKDF2 — the random salt and iteration count ship with the ciphertext. Everything runs inside the browser, so keys, passphrases and plaintext never leave your device — reassuring when handling sensitive content.
GCM is authenticated encryption — besides encrypting it carries an integrity check, so if a single byte of the ciphertext is altered, decryption fails loudly instead of silently returning garbage, unlike CBC. The IV must be unique; leaving the IV empty on encrypt auto-generates a random one (12 bytes for GCM, 16 for CBC). Ciphertext is emitted as a DK1. envelope that carries the mode, KDF, salt and IV, so the receiving side restores everything from that one string.
- Choose encrypt or decrypt: decide which direction this run takes
- Pick a key source: raw key (hex / base64) or passphrase (PBKDF2-derived)
- Pick a mode: GCM (recommended) or CBC (legacy systems)
- Enter the key or passphrase, and the IV: empty IV auto-generates on encrypt
- Run and copy: the output is a DK1. envelope; decrypt by pasting it back with the same key or passphrase
>_ FAQ
Q1 · How does AES-GCM differ from AES-CBC?
GCM is authenticated encryption (AEAD): it adds an authentication tag and verifies integrity on decrypt, so a tampered ciphertext fails outright. CBC provides encryption only, without authentication, so tampering can yield wrong output silently, and you must handle padding and a MAC yourself. Prefer GCM for new work; CBC is kept here for talking to legacy systems.
Q2 · Can I reuse an IV?
No. Under the same key the IV must be unique, ideally a cryptographically random value each time. With GCM, reusing an IV under one key badly weakens security and can leak information about the plaintext. The IV is not secret and may travel with the ciphertext, but it must never repeat. Leaving the IV empty here auto-generates a random 12-byte (GCM) or 16-byte (CBC) value.
Q3 · Why does decryption fail or return garbage?
The usual cause is a mismatch between the two sides: key, passphrase, IV or encoding do not line up, or the ciphertext was altered in transit (GCM then rejects it). If the ciphertext is a DK1. envelope from this tool, the mode / KDF / salt / IV are all restored automatically — only the key or passphrase itself needs checking. For raw ciphertext from external systems, check that the key and IV are byte-for-byte identical and the ciphertext is not truncated or padded with extra whitespace.
Q4 · How long should the key be? Can a password be used directly?
256 bits (32 bytes) or 128 bits (16 bytes) are both considered secure, with 256 leaving more margin. The key should be randomly generated rather than derived from a password directly. The "passphrase" mode here derives keys properly: PBKDF2 with a 16-byte random salt and 100,000 iterations by default (adjustable) yields a 256-bit key, and the derivation parameters travel inside the DK1. envelope — the decrypting side pastes the same ciphertext and the same passphrase, with no out-of-band coordination of salt or IV.
Q5 · How does it relate to the Base64 and HMAC tools?
Their roles differ. Base64 only encodes bytes into printable characters and hides nothing. HMAC only authenticates, proving integrity and origin with a key while the content stays visible. This tool truly encrypts and decrypts, hiding content and (with GCM) checking integrity. Use AES to keep content secret, HMAC to detect tampering and Base64 to encode.