Why does encrypting the same text twice produce different output?

Each encryption run generates a fresh random 16-byte salt and a fresh 12-byte IV. The salt and IV are stored in the JSON package but are not secret; their job is to keep the derived key unique and to keep the AES-GCM initialization vector unique per encryption. That is expected and prevents deterministic ciphertext under the same password.

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

Yes. The salt and IV are stored openly in the JSON envelope because the receiver needs them to derive the same AES key and to initialize AES-GCM. They do not need to be secret; what must remain secret is the password. The 128-bit authentication tag is also visible, and it is the field that proves the password was correct and the package was not modified.

Can Lizely recover a lost password for an encrypted package?

No. Encryption and decryption both run locally in your browser, the password is never uploaded or stored, and there is no recovery or escrow service. If the password is lost, the JSON package cannot be opened, because PBKDF2 with 210,000 iterations cannot be reversed into a key without the original passphrase.

Will another AES tool be able to open this JSON package?

Only if it reproduces every parameter the tool uses: UTF-8 password handling, PBKDF2-SHA-256 with 210,000 iterations, a 16-byte salt, a 12-byte IV, AES-256-GCM with a 128-bit tag at the tail of the ciphertext, and unpadded base64url encoding. The cryptographic ingredients are standardized, but the surrounding JSON field layout is specific to this tool.

AES Encryption Online: Encrypted Text as a JSON Package

AES Encryption Online is a browser-side AES-256-GCM tool that wraps your plaintext inside a versioned JSON package carrying the salt, initialization vector, and 128-bit authentication tag. The encryption key is derived from your password with PBKDF2-SHA-256 at 210,000 iterations and stays non-exportable inside Web Crypto, while the salt and IV are freshly generated for every encryption run. Because the encrypted output is a self-contained JSON envelope instead of an opaque hex string, the receiver needs the JSON package plus the password — and the password travels through a separate channel. Decryption validates the declared labels, field lengths, and base64url syntax before authentication is attempted, so a wrong password or a tampered package produces a clean failure with no partial plaintext. Nothing about the plaintext, password, derived key, or decrypted result is sent to a server, because every operation runs locally in the current page. The JSON layout declares version 1, AES-256-GCM, PBKDF2-SHA-256, and the iteration count, plus base64url fields for the salt, IV, and authenticated ciphertext.

What the AES Encryption Online Package Actually Carries

When a search for "AES encryption online hex" leads you to a hex-centric calculator, the result is normally a raw byte stream encoded as hexadecimal. AES Encryption Online deliberately takes a different route: the output is a structured, self-describing JSON envelope rather than a hex blob. The envelope identifies the version, the algorithm, the key derivation function, the iteration count, and base64url fields for the salt, initialization vector, and authenticated ciphertext. The receiver knows exactly which cipher ran and which parameters were used without out-of-band negotiation, which is part of why the JSON layout is the format the tool emits.

Field	Declared value	Purpose
version	1	Identifies the package layout used by the tool
cipher	AES-256-GCM	Confidentiality plus 128-bit authentication tag
kdf	PBKDF2-SHA-256	Stretches the password into a 256-bit AES key
iterations	210,000	Cost factor raised against password guessing
salt	16 random bytes, base64url	Unique per encryption; not secret
iv	12 random bytes, base64url	Fresh per encryption; required unique for AES-GCM
ciphertext	AES-GCM output plus 128-bit tag, base64url	Encrypted plaintext plus authentication tag

The base64url encoding follows RFC 4648: letters, digits, hyphen, and underscore, with no padding. The 128-bit authentication tag returned by Web Crypto lives at the tail of the ciphertext field. Every other AES tool needs to reproduce those exact choices — UTF-8 password handling, 210,000 iterations, 16-byte salt, 12-byte IV, 128-bit tag, and unpadded base64url — to interoperate with this package. The JSON field layout itself is specific to this tool: the cryptographic ingredients are standardized, but the surrounding envelope is not a universal file format.

Encrypting Text with the AES Encryption Online Tool

The encryption half of the workflow asks for two inputs and produces one portable artifact. Run it directly from the AES Encryption Online page in any modern browser that supports the Web Cryptography API.

Choose Encrypt and enter the plaintext you want to protect. The page treats the input as UTF-8 text.
Enter a unique password of at least 12 UTF-8 bytes. A high-entropy passphrase from a trusted password manager is the only secret in the system.
Run the encryption. The tool generates a fresh 16-byte random salt and a fresh 12-byte random initialization vector, derives a non-exportable 256-bit AES key with PBKDF2-SHA-256 at 210,000 iterations, then encrypts with AES-GCM and appends the 128-bit authentication tag.
Copy the complete JSON package from the result area and store or send it through your controlled channel. The plaintext, password, derived key, and intermediate values never leave the current page.
Deliver the password to the intended recipient through a separate secure channel. The JSON package and the password must travel independently.

Because the salt and IV change every run, encrypting the same plaintext with the same password twice will produce two different JSON packages. That is expected and protects the receiver from inferring equality by comparing ciphertexts.

Decrypting an AES Package and Reading the Result

Decryption reverses the workflow without ever leaving your browser. Open the AES Encryption Online tool, switch to Decrypt, paste the entire JSON package verbatim, and enter the matching password.

The page first validates the JSON shape: declared labels, numeric limits, exact salt and IV lengths, and minimum ciphertext length must all check out before any cryptographic operation is attempted. Only then does Web Crypto re-derive the AES key from the password and the package's stored salt, then authenticate and decrypt the payload. If the password is wrong, if the package was edited, or if the authentication tag does not verify, the tool reports an authentication failure without returning any partial plaintext. The integrity check is the entire point of using GCM mode over CBC or ECB.

Because the package is the only artifact that travels between sender and receiver, treat it as the single source of truth. If anything in the package looks truncated when you paste it back into the tool — a missing closing brace, a stripped line break, or a smart-quoted character where a plain quote was — Web Crypto will refuse the payload and you will see a validation error rather than a decrypted plaintext. Re-copy the package from the original source and try again, this time without any line-ending normalization, before assuming the password is wrong.

Why the Salt, IV, and Tag Live Inside the Package

A few readers land on this tool expecting the kind of raw hexadecimal output that hash generators produce. AES-GCM is more demanding than a plain hash function, so it needs more than one number to recover the message — and each of those numbers plays a specific role.

Salt (16 bytes, public): prevents two recipients with the same password from deriving the same key, and stops precomputed rainbow tables from targeting the tool's layout.
IV (12 bytes, public): AES-GCM requires an initialization vector that is unique for each key. A fresh random IV per run is the simplest way to guarantee that property.
Authentication tag (128 bits, public): stored at the tail of the ciphertext field, this tag lets the decryptor prove the password was correct and the package was not modified in transit.

None of those values are secret. Their job is uniqueness and integrity, not confidentiality. The only secret in the system is the password itself, and the JSON package never contains it. AES-GCM is defined in NIST SP 800-38D; the Web Crypto implementation follows the W3C Web Cryptography Level 2 specification, and the base64url encoding follows RFC 4648. The salt is not secret, the IV is not secret, and the tag is not secret — but the password remains so.

Limits and Operating Boundaries of the Browser-Side Tool

AES Encryption Online is built for controlled text exchanges and demonstrations, not for replacing enterprise key management. Knowing where the boundary sits keeps the tool useful instead of misleading.

The page is designed for small text snippets — passwords, API keys, configuration fragments, JSON snippets, and short messages. There is no file upload, no streaming, no chunking, and no encrypted backup pipeline. PBKDF2 with 210,000 iterations raises the cost of password guessing but cannot rescue a short, reused, leaked, or predictable password. A unique high-entropy passphrase is the only thing standing between your package and an attacker holding the ciphertext. The tool requires at least 12 UTF-8 bytes of password and allows longer passphrases; longer is meaningfully better against guessing.

There is no server-side escrow, no account recovery, and no way for Lizely to recover a lost password, because the password never leaves the page in the first place. The password is never written into the output, and there is no password recovery, escrow, account backup, or server-side key management of any kind.

Browser extensions, clipboard managers, screen capture tools, shared computers, and the destination where the package is pasted all sit outside the cryptographic boundary. Clear sensitive content, close the tab, and treat any other copy of the package as needing the same protection as the plaintext itself. The implementation is checked against NIST AES-GCM vectors, including an empty-plaintext authentication case and a full zero-block encryption case, plus RFC 4648 base64url fixtures. Those checks confirm the defined transformations and the package invariants; they do not certify the surrounding browser, device, password choice, or broader workflow.