AES Decrypt Online — Free AES-256-GCM Text Decryption

Paste a base64 ciphertext, enter the passphrase, and recover the original plaintext. AES-256-GCM with PBKDF2-SHA256 key derivation runs entirely in your browser through the Web Crypto API — passphrase and plaintext never leave the device.

PassphraseLength: 0 chars · PBKDF2-SHA256 · 250,000 iterations

Ciphertext (base64)

Recovered Plaintext

Click Decrypt to recover the plaintext from the AES-256-GCM ciphertext.

Privacy & security: Your passphrase and the recovered plaintext never leave the browser. Decryption uses AES-256-GCM with the GCM authentication tag verifying integrity, and re-derives the key from the embedded salt via PBKDF2-HMAC-SHA256, 250,000 iterations. Wrong passphrase or modified ciphertext fails loudly rather than producing garbage.

What does AES Decrypt do?

This tool reverses the AES Encrypt envelope: it accepts the base64 ciphertext, parses out the embedded salt and IV, re-derives the AES-256 key from your passphrase using PBKDF2-HMAC-SHA256 (250,000 iterations), and runs AES-256-GCM decryption. If the passphrase is correct and the ciphertext was not modified, you get the original plaintext back. If either is off, the GCM authentication check fails and the browser surfaces an error instead of garbage.

All operations use the browser native Web Crypto SubtleCrypto API — the same primitive that backs TLS in Chromium, Firefox, and Safari. The passphrase is held only in a local CryptoKey handle and discarded when the tab closes.

How to decrypt AES-256-GCM online — 4 steps

Paste the ciphertext. Use the full base64 string produced by AES Encrypt — do not edit or split it. Whitespace inside is stripped automatically.
Enter the passphrase. The exact passphrase used at encryption time, byte-for-byte. Watch for stray spaces from copy-paste.
Click Decrypt. The browser re-derives the key with PBKDF2 (~250k SHA-256 hashes) and runs AES-GCM. If the GCM tag verifies, plaintext appears.
Copy the plaintext. Use the copy button to grab the recovered text. Nothing is stored — closing the tab erases it.

Expected ciphertext layout

This page expects the same self-contained envelope produced by the OpenFormatter AES Encrypt tool. Anything different — a separate IV field, a different KDF, raw AES-GCM without a salt — will fail to decrypt.

base64( salt(16 bytes)  ||  iv(12 bytes)  ||  ciphertext(N + 16 bytes GCM tag) )

  bytes 0..15    salt   — fed to PBKDF2-SHA256, 250,000 iterations, with the passphrase
  bytes 16..27   iv     — required by AES-GCM, must match the encryption-time IV
  bytes 28..end  ct+tag — AES-256-GCM ciphertext with 128-bit authentication tag

# Decryption:
#   1. base64 decode
#   2. slice salt, iv, ct
#   3. PBKDF2(passphrase, salt, 250000, SHA-256) -> 256-bit key
#   4. AES-GCM decrypt(key, iv, ct) -> plaintext (or error if tag invalid)

Authenticated AES-GCM

Decryption checks the 128-bit GCM tag before returning plaintext. Tampered ciphertext or wrong key fails loudly — never silently produces wrong data.

PBKDF2 Re-Derivation

250,000 iterations of HMAC-SHA256 with the embedded salt. The same key is reproduced exactly when the passphrase matches — no key file needed.

Browser-Only Crypto

Web Crypto SubtleCrypto runs decryption inside your browser. The passphrase, derived key, and plaintext never reach any server.

Common use cases

check_circleRecovering a stored recovery phrase or seed words from an encrypted note
check_circleReading API keys or database credentials shared by a teammate over chat
check_circleUnwrapping a .env snapshot pasted into a private gist or ticket
check_circleRestoring local-first app payloads or encrypted journal entries
check_circleVerifying that a backup script's ciphertext is still readable with the documented passphrase
check_circleInspecting the plaintext during a security review of an AEAD wrapper
check_circleReproducing fixtures in unit tests of decrypt logic against a browser baseline
check_circleDemonstrating GCM authentication failure by flipping a single bit and re-decrypting

Why decryption can fail (and how to fix it)

AES-GCM is intentionally strict — the entire point of authenticated encryption is to refuse rather than guess. If you see a decryption error, work through these in order:

Passphrase typo. Most common. Re-type instead of pasting, or use the show toggle to verify visually.
Stray whitespace. Some chat clients and email pipelines wrap base64 with newlines or insert non-breaking spaces. The tool strips standard whitespace, but exotic Unicode space characters survive — re-copy from the source.
Wrong envelope. Ciphertext from a different library (different salt size, iteration count, IV size, or a JSON wrapper) will not decrypt here even with the correct passphrase. This page implements the OpenFormatter AES Encrypt format only.
Modified ciphertext. Even one flipped bit causes the GCM tag check to fail — that is by design. Get a clean copy from the original source.

Why client-side decryption matters

A web tool that asks for your decryption passphrase and then sends both passphrase and ciphertext to a server is a credential-harvesting risk — even if the operator is honest, anything in their logs, traces, or memory dumps becomes a future leak. OpenFormatter performs decryption entirely in JavaScript with the browser's Web Crypto API. The passphrase never crosses the network; the recovered plaintext lives only in this tab. Open DevTools → Network and click Decrypt — there is no outbound request.

Need to encrypt or generate keys?

Pair this tool with the rest of OpenFormatter's browser-side security toolkit.

AES Encrypt Hash Generator UUID Generator

Frequently Asked Questions

What ciphertext format does this tool accept?

Base64 of the layout salt(16 bytes) || iv(12 bytes) || ciphertext-with-gcm-tag, exactly as produced by the OpenFormatter AES Encrypt tool. The salt is used to re-derive the AES-256 key with PBKDF2-HMAC-SHA256 (250,000 iterations); the IV and tag are consumed by AES-GCM. You only need the base64 string and the passphrase — nothing else to track.

Why does decryption fail with a valid-looking passphrase?

AES-GCM is authenticated: if the derived key is wrong by a single bit, or if any byte of the ciphertext or tag was modified in transit, the tag check fails and the browser refuses to return plaintext. The two common causes are (1) a typo in the passphrase, often a leading/trailing space picked up by copy-paste, and (2) an extra newline or character pasted into the ciphertext field. Re-paste both and try again.

Is my passphrase sent to a server?

No. Decryption runs entirely inside your browser through the Web Crypto SubtleCrypto API. The passphrase, derived key, and recovered plaintext exist only in this tab. Open DevTools → Network and click Decrypt — there are zero outbound requests.

Can I decrypt ciphertext produced by another library?

Only if it uses the exact same envelope: PBKDF2-HMAC-SHA256 with 250,000 iterations, AES-256-GCM, 16-byte random salt, 12-byte random IV, and the layout salt || iv || ciphertext+tag, base64-encoded. Different parameter choices (different iteration count, different hash, different IV/salt sizes, fields stored separately) will appear to be valid base64 but will fail the GCM authentication check.

Does this tool log my plaintext?

No. There is no telemetry, no analytics on input fields, and no server round-trip during decryption. The only network requests this page makes are the initial HTML, JS, CSS, and font assets — verifiable in DevTools.

What if the ciphertext was modified in transit?

AES-GCM detects it. The 128-bit authentication tag baked into the ciphertext is checked during decryption — if the bytes were altered, even by one bit, the SubtleCrypto decrypt call throws and you see an error. This is the entire point of authenticated encryption: integrity and confidentiality together.

How long can a ciphertext be?

AES-GCM permits up to ~64 GB per (key, IV) pair, so for any reasonable text payload there is no length limit. The browser may slow down rendering very large outputs in the textarea, but the cryptography is unbothered. For multi-gigabyte payloads, use a streaming API in code rather than this UI.

Why use PBKDF2 instead of just hashing the passphrase?

A single SHA-256 of the passphrase would let an attacker test billions of guesses per second on a GPU. PBKDF2 with 250,000 iterations forces ~250,000 SHA-256 operations per guess, slowing brute force by the same factor. The random salt makes precomputed rainbow tables useless. Modern alternatives like Argon2id are even better; PBKDF2 is used here because it is the only KDF natively available in the Web Crypto API.