AES Encryption Online encrypts text with AES-256-GCM and packages the result into a self-contained, portable JSON file that you can store, copy, or send, with decryption running entirely inside the current browser tab. The implementation uses PBKDF2-SHA-256 with 210,000 iterations to derive a 256-bit key from your password, then encrypts with a fresh 12-byte initialization vector and a 128-bit authentication tag. Because AES-GCM is authenticated encryption, the package also detects tampering: if a single byte is altered or the password is wrong, decryption fails without ever showing partial plaintext. Salt and IV values are stored openly in the package because they exist to make key derivation unique and ciphertext non-deterministic, not to be secret. The full pipeline runs through the browser Web Crypto API, so plaintext, password, derived key, and decrypted result are never submitted to Lizely. The output is a portable JSON package that you can save as a file with a .json extension and decrypt later on the same page or on any device that reproduces the same field layout, UTF-8 handling, PBKDF2 parameters, and base64url encoding.
How AES-256-GCM Online Encryption Works
AES-GCM combines a 256-bit AES block cipher in counter mode with a Galois authentication field, giving you both confidentiality and integrity in a single primitive. The Galois field is what produces the 128-bit tag appended to the ciphertext: when you decrypt, the browser recomputes the tag and compares it to the value inside the package, and any mismatch is treated as a hard failure rather than a soft warning. That is why AES Encryption Online can guarantee "no partial plaintext on the wrong password": the decryption step either succeeds with the original text or refuses to run.
PBKDF2 sits in front of AES-GCM to convert your human-memorable password into a uniform 256-bit key. The tool derives that key with SHA-256, a 16-byte random salt, and exactly 210,000 iterations, and the salt is stored inside the package so the same key can be rebuilt later from the same password. PBKDF2 is not a substitute for password quality; it simply raises the cost per guess. A short, reused, leaked, or predictable passphrase collapses that defense, which is why the interface enforces a minimum of 12 UTF-8 bytes and recommends pulling a unique high-entropy passphrase from a password manager instead of inventing one.
Randomness is generated by the browser each time you encrypt. The tool requests a fresh 16-byte salt and a fresh 12-byte IV for every run, so the same plaintext under the same password produces a different package every time. This non-determinism is what hides equality: an observer who only sees packages cannot tell that two encrypted messages contain identical text. The IV is required to be unique per key by AES-GCM itself, and reusing an old IV by editing the package would silently destroy authentication, which is why the JSON format freezes salt, IV, ciphertext, and tag together as one immutable record.
Encrypt a File Online in Three Steps
Follow these steps to produce an authenticated AES-256-GCM file package with AES Encryption Online.
- Open the AES Encryption Online tool and choose the Encrypt mode. Type or paste your plaintext into the input area and enter a unique password of at least 12 UTF-8 bytes, ideally a high-entropy passphrase from a trusted password manager. Click the encrypt action to run AES-256-GCM encryption with a freshly generated salt and IV.
- Copy the complete JSON package from the output area and save it exactly as produced, including every field and every base64url character. Keep the password in a separate secure channel such as a password manager vault, an out-of-band message, or a sealed note; never bundle the password into the same file or message as the package.
- To decrypt, return to the tool, choose the Decrypt mode, and paste the JSON package unchanged into the input area. Enter the same password you used for encryption and run the decryption action. If the password is correct and the package has not been altered, the original plaintext is restored. If anything is wrong, the tool reports an authentication failure and returns no plaintext.
Treat the package as a single atomic object. Removing a field, normalizing whitespace, swapping base64url for padded Base64, or replacing the IV with a previous value will all make validation fail, because the tool checks field labels, numeric limits, field syntax, exact salt and IV lengths, and minimum ciphertext length before asking the Web Crypto API to authenticate and decrypt.
Inside the JSON File Package
The output is not a raw binary blob but a structured JSON document. Each field has a defined meaning, and together they tell any compliant decryptor exactly how to rebuild the AES key and verify the tag.
| Field | Purpose | Format |
|---|---|---|
| version | Format identifier | Integer, value 1 |
| algorithm | Cipher declaration | String AES-256-GCM |
| kdf | Key derivation function | String PBKDF2-SHA-256 |
| iterations | PBKDF2 iteration count | Integer, value 210000 |
| salt | Random salt for key derivation | Base64url, 16 bytes |
| iv | Random initialization vector | Base64url, 12 bytes |
| ciphertext | Encrypted bytes plus 128-bit GCM tag | Base64url, at least 16 bytes |
Base64url is unpadded, following RFC 4648, so a package does not contain the +, /, or = characters of standard Base64. The GCM authentication tag is appended to the ciphertext rather than stored in a separate field, which matches how the W3C Web Cryptography API returns AES-GCM output. Any other system that wants to decrypt a package must reproduce this UTF-8 handling, these PBKDF2 parameters, this tag placement, and this exact base64url alphabet; the cryptographic ingredients are standardized, but the surrounding JSON layout is specific to this tool.
Password Rules and the Security Boundary
The 12-UTF-8-byte minimum is a usability floor, not a strength guarantee. PBKDF2-SHA-256 at 210,000 iterations slows down a brute-force search, but it cannot rescue a passphrase that has been reused, leaked, or chosen from a small dictionary. For meaningful protection, generate a long random passphrase from a Password Generator, store it in a password manager, and treat the JSON package as you would treat any other authenticated file: keep it on devices you trust, on storage you control, and on channels that preserve it byte-for-byte.
The cryptographic boundary stops at the page. Browser extensions that read the DOM, compromised host devices, clipboard managers that log past copies, screen-capture tools, shared computers, and any system that receives the pasted package are all outside the protection that AES-GCM offers. The tool is a single transformation: it converts a password and a plaintext into an authenticated package, or it converts a package and a password back into a plaintext. It does not manage sessions, vaults, or keys across visits, and there is no password recovery, no escrow, and no server-side key material. Clear sensitive content from the page and close the tab when the surrounding device is no longer trusted.
What AES Encryption Online Is Not For
The tool is designed for small text snippets, demonstrations, controlled exchanges between two parties who already share a password, and compatibility experiments with the documented JSON layout. It is not a managed vault, an enterprise key-management service, an encrypted backup system, or a substitute for reviewed application-level cryptographic design. Treat it the way you would treat any other single-purpose primitive: useful in scope, narrow in responsibility, and dependent on the surrounding workflow for real security. For wider compatibility work, the W3C Web Cryptography Level 2 specification describes how the underlying AES-GCM and PBKDF2 primitives behave in compliant browsers, which is the contract this tool follows.
Compare the limits with the capabilities in the table below to set expectations before you start.
| Use case | Fits AES Encryption Online | Requires a different system |
|---|---|---|
| Send a short secret over an existing channel | Yes, copy the JSON package, share the password out of band | No |
| Encrypt a multi-megabyte file | No, designed for text snippets | File-encryption tool with streaming AEAD |
| Recover a forgotten password | No recovery, no escrow | Vault with documented recovery flow |
| Interoperate with a third-party AES utility | Only if it reproduces the exact JSON layout and PBKDF2 parameters | Open-format container such as age, GPG, or a CMS envelope |
| Run inside a regulated enterprise workflow | No, browser-only and stateless | HSM-backed key management service |
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. Those checks prove that the defined transformations and package invariants behave as documented; they do not certify the browser, the device, the chosen password, the storage location, or the broader workflow around the tool.