Your files never leave your device. All processing happens locally in your browser.
How do I encrypt and decrypt text with AES in the browser without uploading it?
Open the AES Encryption / Decryption tool, pick Encrypt, type a strong passphrase and paste your text — a self-contained encrypted token appears instantly. It uses real AES-256-GCM via the browser’s Web Crypto API: a fresh random 16-byte salt is generated, PBKDF2-HMAC-SHA-256 (default 210,000 iterations, up to 600k) stretches your passphrase into a 256-bit key, and the UTF-8 text is encrypted with a fresh random 12-byte IV. The output is one base64 token containing version ‖ iterations ‖ salt ‖ IV ‖ ciphertext + 128-bit GCM tag, so to reverse it you switch to Decrypt, enter the same passphrase and paste the token — the tag is verified and a wrong passphrase or any tampering is refused. Everything runs on your device; the text, passphrase and token never leave the browser.
Real AES-256-GCM + PBKDF2-HMAC-SHA-256 via the Web Crypto API — not a mock
Fresh random 16-byte salt and 12-byte IV per message (crypto.getRandomValues)
One self-contained base64 token (or PEM-like armored block) — decrypt needs only the token + passphrase
Authenticated: a wrong passphrase or a tampered token fails to decrypt; a lost passphrase is unrecoverable
What is
AES-256-GCM passphrase encryption (in the browser)
AES-256-GCM passphrase encryption turns readable text into an unreadable token that can only be reversed with the correct passphrase. A 100% client-side version derives a 256-bit key from the passphrase with PBKDF2-HMAC-SHA-256 over a random salt, then encrypts the text with AES-256 in Galois/Counter Mode using a random IV; GCM is an authenticated cipher, so its 128-bit tag also detects any tampering. The salt, IV and parameters are packed with the ciphertext into a single self-contained token, and all of it happens in the browser via the Web Crypto API so nothing is uploaded.
No. All encryption and decryption run on your device via the browser’s Web Crypto API; nothing is uploaded.
The tool is 100% client-side. Key derivation (PBKDF2), encryption and decryption (AES-256-GCM) all run locally through window.crypto.subtle, and every random salt and IV comes from crypto.getRandomValues — the browser’s cryptographically secure generator. Your text, your passphrase and the resulting token are never fetched, uploaded, logged or stored on a server, there is no CDN in the processing path, and the tool works offline once cached. Close the tab and nothing is left behind.
Decryption is refused. GCM is authenticated, so a wrong passphrase or any tampering fails the 128-bit tag check.
AES-GCM is an authenticated cipher: alongside the ciphertext it stores a 128-bit tag computed over the data. On decryption the browser recomputes that tag, and if the passphrase is wrong or even a single byte of the token was altered, the check fails and the tool shows “wrong passphrase, or the encrypted text was altered or corrupted” rather than returning garbled or subtly wrong text. This tamper-detection is a real security property, not a formatting check.
More iterations slow down offline guessing. The default is 210,000; OWASP suggests 310k–600k for PBKDF2-SHA-256.
PBKDF2 deliberately repeats a hash many times so that testing each candidate passphrase is expensive, which slows an attacker who has your token and is brute-forcing passphrases offline. The tool ships a balanced default of 210,000 iterations and lets you choose 100k, 210k, 310k (OWASP’s 2025 minimum for PBKDF2-HMAC-SHA-256) or 600k (OWASP’s recommended figure). Higher is stronger but slower on every device, including yours. The exact count is written into the token, so decryption always uses the right value automatically. Note PBKDF2 is not memory-hard — Argon2 or scrypt resist GPU cracking better.
No. There is no backdoor, reset or key escrow — a lost passphrase means the data is unrecoverable.
The passphrase is the only thing that can derive the key, and it is never stored anywhere. If you lose it, the encrypted token is mathematically unrecoverable — that is the whole point of strong encryption, and it is why you should store your passphrase safely (for example in a password manager). Equally, security depends entirely on passphrase strength: AES cannot protect a short or common passphrase, which is guessable by brute force no matter how many iterations you choose. Use the strength meter and the built-in secure random generator, and for high-stakes or regulated data rely on audited, purpose-built tools.
Detailed Explanation
📖How It Works
What the AES Encryption / Decryption Tool Does
The AES Encryption / Decryption tool is a 100% client-side text encryptor built on the browser’s Web Crypto API. In Encrypt mode the user types a passphrase and some text and instantly gets one self-contained encrypted token; in Decrypt mode they paste the token and the same passphrase to recover the original text. It uses real, standard cryptography — AES-256 in GCM (an authenticated cipher) with a key derived from the passphrase by PBKDF2-HMAC-SHA-256 — and every operation runs locally, so the text, the passphrase and the token never leave the device. It is the free, private answer to “encrypt this note so only someone with the passphrase can read it”, without pasting sensitive text into a website that uploads it.
Encrypt / decrypt UTF-8 text with AES-256-GCM via window.crypto.subtle
Key derived from the passphrase with PBKDF2-HMAC-SHA-256
Output is one self-contained token; decryption needs only the token + passphrase
Live, debounced processing with a passphrase strength meter and generator
No upload, no server, no CDN in the processing path — works offline once cached
⚙️Methodology
How the Encryption Works (PBKDF2 → AES-256-GCM)
For each message a fresh random 16-byte salt is generated with crypto.getRandomValues. PBKDF2-HMAC-SHA-256 stretches the passphrase over that salt (default 210,000 iterations, selectable 100k / 210k / 310k / 600k) into a 256-bit key. The UTF-8 plaintext is then encrypted with AES-256-GCM using a fresh random 12-byte IV; GCM produces a 128-bit authentication tag appended to the ciphertext. The salt, IV, iteration count and a version byte are packed with the ciphertext+tag and base64-encoded into a single token, so nothing external needs to be stored. Decryption reverses this: it parses the header, re-derives the key with the token’s own iteration count and salt, then AES-GCM verifies the tag before returning plaintext — a wrong passphrase or any tampering fails authentication.
Fresh random 16-byte salt and 12-byte IV per message (crypto.getRandomValues)
Iteration count stored in the token so decryption uses the right cost automatically
Decrypt verifies the GCM tag before returning any plaintext
🔧Technical Details
Self-Contained Token Format
The token is base64 of a compact binary payload: a 1-byte version, a 4-byte big-endian iteration count, the 16-byte salt, the 12-byte IV, then the AES-GCM ciphertext with its trailing 16-byte tag (HEADER_BYTES = 33). Because every parameter needed to reverse the operation is embedded, the recipient needs only the token and the passphrase — there is no separate key file or metadata. The tool offers two equivalent output shapes: a compact base64 string, or a PEM-like armored block wrapped in -----BEGIN ANYTOOL ENCRYPTED----- / -----END ANYTOOL ENCRYPTED----- for easy pasting into email or chat. A tiny header version lets the format evolve without breaking existing tokens, and the parameters panel shows the exact cipher, KDF, iterations, salt/IV sizes, ciphertext bytes and token length in real time.
Compact base64 or PEM-like armored block — same data either way
Versioned so the format can evolve without breaking old tokens
Live parameters panel shows cipher, KDF, iterations and sizes
⚠️Limitations
Honest Limitations and Threat Model
The cryptography is real and standard, but it only protects a token against someone who has the token yet not the passphrase (encrypted at rest or in transit). Security depends ENTIRELY on passphrase strength — AES cannot save a short or common passphrase, which is brute-forceable offline no matter how many iterations you choose, so use the strength meter and the secure generator. A lost passphrase makes the data unrecoverable: there is no backdoor, reset or key escrow, by design. It does NOT defend against malware, keyloggers, a compromised browser or extension, shoulder-surfing, or clipboard/history snooping on your own machine. Browser caveats apply: JavaScript cannot reliably wipe a passphrase from memory, and metadata such as the token’s length is not hidden. PBKDF2 is standard but not memory-hard — Argon2 or scrypt resist GPU/ASIC cracking better. Treat this as a convenience tool; for high-stakes, regulated or life-safety data use audited software (GnuPG, age, a vetted password manager) with expert review.
Security depends entirely on passphrase strength; AES cannot fix a weak one
Lost passphrase = unrecoverable data (no backdoor / reset / escrow)
No defence against malware, keyloggers, or a compromised device / clipboard
JS cannot reliably wipe secrets from memory; token length is not hidden
PBKDF2 is not memory-hard — Argon2 / scrypt resist GPU cracking better
🔒Privacy & Security
Private by Design
Everything happens on the device. Key derivation (PBKDF2), encryption and decryption (AES-256-GCM) all run through the browser’s native Web Crypto API (window.crypto.subtle), and every random salt and IV comes from crypto.getRandomValues — never Math.random. The plaintext, the passphrase and the resulting token are never fetched, uploaded, logged or stored on a server; there is no CDN in the processing path, no analytics and no telemetry. The tool works offline once cached and keeps no accounts. This matters because people reach for a text encryptor precisely when the text is sensitive — a recovery phrase, a password, a private note — and such text should never round-trip through a third-party service just to be encrypted. The only optional network use anywhere on the page is consent-gated ads, which are outside the crypto path.
PBKDF2 + AES-256-GCM run locally via window.crypto.subtle
All randomness from crypto.getRandomValues — never Math.random
Text, passphrase and token never leave the browser; no CDN, no telemetry
Works offline once cached; no accounts
Only optional network use is consent-gated ads (outside the crypto path)
Ways to encrypt a piece of text with a passphrase
Approach
How it works
Trade-off
Used here
This client-side tool
PBKDF2-HMAC-SHA-256 → AES-256-GCM via Web Crypto; self-contained base64 token
Private + free + offline; standard crypto, but only as strong as the passphrase (PBKDF2 not memory-hard)
Yes
Server-side / online encryptors
Text is sent to a website that encrypts it and returns a token
Convenient, but the plaintext and passphrase can be seen or logged by the server
No
GnuPG (OpenPGP)
Symmetric or public-key encryption in an audited desktop toolchain
Battle-tested and full-featured, but needs install and command-line comfort
Complement
age / scrypt / Argon2 tools
Modern file encryption with memory-hard key derivation
Stronger against GPU cracking and great for files, but a separate app
Alternative
Everything here runs in the browser via the Web Crypto API; the text, passphrase and token are never uploaded. Real AES-256-GCM + PBKDF2-HMAC-SHA-256, but security depends on passphrase strength and a lost passphrase is unrecoverable. As of July 2026.
