Are the salt and IV supposed to be visible in the package?

Yes. They are stored in the JSON package for key derivation and decryption and do not need to be secret. The password must remain secret.

Why does encrypting the same text twice produce different output?

Each run generates a fresh random 16-byte salt and a fresh 12-byte IV. That is expected and prevents deterministic ciphertext under the same password.

Can I decrypt a package with a different tool?

Only if that tool reproduces the same UTF-8 handling, PBKDF2-SHA-256 with 210,000 iterations, the 12-byte IV, the 128-bit GCM tag placement, and the exact JSON field layout with unpadded base64url.

AES Decrypt Online: Open a JSON Package With Its Password

Q: Can Lizely recover a lost password?

No. Encryption and decryption are local, the password is never uploaded or stored, and there is no recovery or escrow service.

AES decryption with the Lizely tool runs entirely in the browser through the Web Crypto API, requires the exact password used to encrypt, and returns the original plaintext only when the 128-bit authentication tag verifies the package. If any byte of the JSON package has changed, or if the password differs in a single byte, the tool rejects the input and shows an authentication failure without leaking any portion of the plaintext. The output is never transmitted off the page, the password is never written into the package, and Lizely has no server-side record of either value, so the only way to decrypt an existing package is to bring the package and the password to the same browser session.

What "AES Decrypt Online" Means With This Tool

Searching for "AES decrypt online" usually means you already have an AES-encrypted package and want a fast way to recover the original text. AES Encryption Online does exactly that, but with one important constraint: the input is not raw Base64 ciphertext, it is a structured JSON package. The package embeds everything decryption needs, including the AES mode label, the PBKDF2 iteration count, the random salt, the random initialization vector, and the authenticated ciphertext, alongside the 128-bit GCM authentication tag. You paste the package, type the password, and run decryption locally; if Web Crypto validates the package and the tag, you see the original plaintext on the page and can copy it back out as text.

The decryption path is the exact reverse of the encryption path. PBKDF2-SHA-256 with 210,000 iterations converts the UTF-8 password and the stored salt into a non-exportable 256-bit AES key, AES-GCM uses the stored IV with that key to verify the tag, and only then releases the decrypted bytes. Because every step happens in the browser, you can use the page on any modern Chromium, Firefox, or Safari installation without installing software, registering an account, or trusting a remote service with your password.

Run Decryption on an AES Package

Follow these concrete steps to decrypt an existing AES-256-GCM JSON package using AES Encryption Online in decrypt mode.

Switch the tool to Decrypt mode and paste the complete JSON package into the package field exactly as it was copied, with no trailing whitespace removed and no fields edited.
Type the password that was used during encryption into the password field. The minimum length is 12 UTF-8 bytes, but the password must be byte-identical, so capitalization, spacing, and invisible Unicode characters all matter.
Run the decryption. The tool validates the JSON labels, numeric limits, field syntax, exact 16-byte salt length, exact 12-byte IV length, and minimum ciphertext length before invoking Web Crypto.
Read the result. On success, the original plaintext appears in the output area and can be copied as text. On failure, the tool reports an authentication error and shows no partial plaintext.
Clear the password and the output, then close the tab when you are done if the device is not fully trusted.

Anatomy of an AES-256-GCM JSON Package

The JSON package is a self-describing container that carries every value the browser needs to recreate the AES key and verify the tag. Understanding what each field does makes decryption failures much easier to diagnose. The labels are case-sensitive and the field syntax is strict; the table below summarizes what each field carries and how the tool uses it.

Field	Encoding	Purpose during decryption
version	integer	Confirms the package layout is v1. Anything other than 1 is rejected.
cipher	string "AES-256-GCM"	Declares the mode and key size so the browser picks the right Web Crypto algorithm.
kdf	string "PBKDF2-SHA-256"	Tells the browser to derive the AES key with PBKDF2-HMAC-SHA-256.
iterations	integer	Iteration count used during key derivation. The tool currently uses 210,000.
salt	base64url	16-byte random salt. Stored openly because its purpose is uniqueness, not secrecy.
iv	base64url	12-byte random initialization vector. Must be unique per key; the tool generates a fresh value for every encryption.
ciphertext	base64url	Authenticated ciphertext including the 128-bit GCM tag returned by Web Crypto.

The package layout is specific to this tool. Its cryptographic primitives are standardized, but the surrounding JSON envelope is not a universal file format, so another system can only interoperate if it reproduces the same UTF-8 handling, PBKDF2 parameters, AES-GCM tag placement, base64url encoding, and field names. Keep the whole package unchanged when decrypting; removing a field, normalizing its text incorrectly, or inserting conventional padded Base64 where base64url is expected will make validation fail before Web Crypto is ever called.

Why Authentication Failures Show No Partial Plaintext

AES-GCM combines encryption with authentication. When the tool asks Web Crypto to decrypt, the browser first recomputes the authentication tag from the ciphertext, IV, and derived key, and compares it against the tag stored in the package. Only if the two tags match byte-for-byte does the browser release the decrypted plaintext. If the password is wrong, the derived key changes, the recomputed tag no longer matches, and decryption aborts before any plaintext byte is returned.

The same thing happens if anyone edits the package. Reusing an old IV with the same ciphertext, trimming whitespace the JSON parser did not originally see, or substituting standard Base64 for base64url will all cause validation or authentication to fail. The strict pre-validation step rejects malformed packages with a clear error before Web Crypto is even called, while a structurally valid but tampered package fails at the GCM tag check. In both cases the tool reports an authentication failure and does not display any partial plaintext, which is the behavior you want from an authenticated cipher and the reason the failure tells you nothing about how close the password was.

Password Requirements and Common Decryption Failures

The interface requires at least 12 UTF-8 bytes of password and accepts longer passphrases. PBKDF2 with 210,000 iterations raises the cost of guessing the password, but it cannot rescue a short, reused, leaked, or predictable password. Decryption success depends on the password being byte-identical to the one used during encryption; a single wrong character, a different Unicode normalization form, or an autofilled password with hidden trailing whitespace will all produce an authentication failure even when the package itself is perfectly intact. Lizely cannot recover a lost password, because encryption and decryption are local, the password is never uploaded or stored, and there is no recovery or escrow service behind the page.

If decryption keeps failing, walk through this short checklist before assuming the package is corrupt:

Confirm the package came from this exact tool and has not been edited, pretty-printed differently, or re-saved by a text editor that stripped trailing characters.
Re-enter the password manually rather than relying on a clipboard manager, browser autofill, or password manager that may have added invisible bytes.
Check that the field labels in the JSON are spelled exactly as listed in the table above; the tool rejects unknown fields and version numbers other than 1.
Make sure the base64url fields contain only unpadded base64url characters. Adding "=" padding or substituting standard Base64 will fail validation before Web Crypto ever runs.
Verify that the receiving device is not affected by clipboard managers, browser extensions, or screen capture that could leak the plaintext after decryption succeeds.

When AES Decryption Online Is the Right Fit

The tool fits small text snippets, demonstrations, controlled exchanges between two people who already share a password out of band, and compatibility experiments where you want to inspect the exact JSON layout a browser produces. It is also a fast way to verify a package you received: paste it, type the password, and either the original text appears or you get a clear authentication error. Nothing leaves the page, so it is appropriate when the device itself is trusted and the surrounding workflow keeps the password in a separate secure channel such as a password manager or an end-to-end-encrypted message.

It is not a managed vault, an enterprise key management service, an encrypted backup system, or a substitute for reviewed application-level cryptographic design. Browser extensions, compromised devices, clipboard managers, screen capture, shared computers, and the destination where you paste the decrypted text all sit outside the cryptographic boundary. Generate a strong unique passphrase from a trusted password manager for meaningful protection, review its length and obvious patterns before relying on it for anything sensitive, then clear the output and close the tab when the surrounding device is not trusted. The implementation is checked against NIST AES-GCM vectors, including an empty plaintext authentication case and a full zero-block encryption case, and the base64url fixtures follow RFC 4648, while the AES-GCM, PBKDF2, and key derivation behavior follow the W3C Web Cryptography specification.