AES-256 Encrypt/Decrypt

Overview

Encrypts and decrypts text with AES-256-GCM using the browser's native Web Crypto engine, deriving the key from your password with PBKDF2-SHA256 at 150,000 iterations. Every encryption embeds a fresh random salt and IV in the output, so the same passphrase never produces the same payload twice, and nothing you type is transmitted anywhere.

How It Works

Switch between Encrypt and Decrypt, enter a password, and type your text. Encrypting produces a single dot-separated payload of three base64 chunks: salt, IV, and ciphertext. Decrypting expects exactly that format, rebuilds the key from the salt, and returns your original text or a clear failure. A wrong password or a corrupted payload fails with an explicit error rather than returning garbage, because GCM authentication rejects the result.

Step-by-Step Usage Guide

1. Choose Encrypt, type a strong passphrase, and paste the text you want to protect. Both fields are required; the tool tells you if one is missing.
2. Press Encrypt and copy the salt.iv.ciphertext payload from the result box. Each run produces a different payload even for identical input.
3. To decrypt, switch to Decrypt, paste the exact payload, and enter the same passphrase. Format errors and wrong passwords produce distinct, specific messages.
4. Keep the payload and the passphrase apart when sharing: the payload alone is useless without the password, and the password alone reveals nothing.

Technical Specifications & Standards

The cipher is AES-256-GCM, the authenticated-encryption mode NIST SP 800-38D specifies, with the 96-bit (12-byte) IV that recommendation urges for interoperability. The key is not your password: it is derived with PBKDF2 (RFC 2898) using HMAC-SHA-256, a fresh 16-byte salt and 150,000 iterations, then used as a non-extractable AES-GCM key. On encryption the tool draws a random salt and a random IV from crypto.getRandomValues, so a plaintext encrypted twice yields completely different payloads - a property fixed-IV modes famously lack. The payload layout, salt.iv.ciphertext in unpadded base64, is this tool's own format, so a payload encrypted here can only be decrypted here unless you reproduce the same steps elsewhere. One honest calibration: OWASP's Password Storage Cheat Sheet recommends 600,000 PBKDF2-HMAC-SHA-256 iterations for storing passwords; this tool's 150,000 is a key-derivation cost, not a stored-password verifier, but it is below that benchmark, and a determined offline attacker holding your payload can guess passwords at PBKDF2 speed.

Targeted Use Cases

• Exchanging a snippet of sensitive text - a staging API key, a recovery note - through a channel you do not fully trust, with the passphrase delivered separately.
• Verifying that your own AES-GCM implementation agrees with Web Crypto on the same salt, IV and key.
• Producing realistic ciphertext fixtures for tests, where a random salt and IV matter more than long-term secrecy.
• Learning how authenticated encryption behaves: a flipped bit in the payload causes a hard failure, not silent corruption.

Notes & Gotchas

• Use a long, unique passphrase. The security of the payload reduces to the difficulty of guessing it, since the salt and IV travel in the clear inside the payload.
• Do not treat a browser tab as a secure vault. This is for transport and testing, not for protecting production keys; the passphrase exists in page memory while you work.
• Re-encrypt rather than editing in place: the format has no mutation story, and a payload from an older session decrypts fine as long as you kept the passphrase.
• Deliver the passphrase out of band. An encrypted payload and its password in the same email channel protects against nothing.

Frequently Asked Questions