AES-256-GCM pairs a 256-bit key with a 128-bit authentication tag, and AES Encryption Online turns each run into a self-contained, version-1 JSON package that the browser can copy, store, or decrypt later. The tool is free, runs entirely through the browser Web Crypto API, and never uploads plaintext, passwords, derived keys, or decrypted results to Lizely. Every run uses a fresh 16-byte random salt, a fresh 12-byte random initialization vector, and PBKDF2-SHA-256 with 210,000 iterations to derive a non-exportable 256-bit AES key. Encrypt and decrypt are intentionally symmetric operations: encrypt produces the JSON package, decrypt consumes it, and an authentication failure is reported without ever returning a partial plaintext. Because the salt and the IV are regenerated for every run, encrypting the same plaintext under the same password still produces a different package each time, which is the property that makes the JSON layout portable across browsers. The field layout is specific to this tool, so any other system needs to reproduce the exact PBKDF2 parameters, AES-GCM tag placement, and base64url fields to interoperate.
How a free AES tool works in your browser
Searching for an AES encryption service typically splits the results into three patterns: a no-signup web app that runs in the browser, a downloadable library you embed in code, or a server endpoint that handles keys on your behalf. AES Encryption Online fits the first pattern and goes a step further by keeping every cryptographic operation inside the current tab. The plaintext, password, derived key, and decrypted output live in page memory until you close the tab; nothing is submitted to a backend, no account is required, and no telemetry is attached to the data you are protecting. The tool refuses to act as a managed vault or as an enterprise key-management service, and it cannot recover a password that has been lost because the password is never written to the package and never crosses the network.
The package that comes back from encryption is a plain JSON object that you can paste into an email, a chat message, a ticket, or a file as long as you keep it byte-identical. Decryption is the inverse: paste the unchanged package, supply the same password, and the same tab reconstructs the original plaintext only when every byte, label, length, and authentication tag matches. Because the format declares what it is and what it expects, you do not need to install software, copy libraries, or configure a server to round-trip a small text snippet between machines.
Encrypt text into a portable JSON package
This is the half of the workflow that produces the bundle you can later move or store. The interface gives a single encrypt path with a few required inputs and reports the package only when the input is well-formed enough to succeed.
- Choose Encrypt, then type or paste the plaintext you want to protect into the input area.
- Enter a unique password of at least 12 UTF-8 bytes; longer passphrases from a trusted password manager are recommended.
- Run AES-256-GCM encryption. The tool generates a fresh 16-byte salt and a fresh 12-byte IV, derives a non-exportable 256-bit key with PBKDF2-SHA-256 and 210,000 iterations, encrypts with AES-GCM, and appends a 128-bit authentication tag to the ciphertext.
- Copy the complete JSON package and preserve it unchanged while you move the password through a separate secure channel such as a different messenger, a password manager, or an out-of-band call.
Two precautions matter at this stage. First, the package is opaque once generated, so editing a field, swapping the salt, or replacing the IV will break authentication on the next decrypt. Second, because both the salt and the IV are regenerated for every run, encrypting the same plaintext under the same password produces a different package every time. That is by design, and it is one of the reasons the package is portable: it carries all the non-secret randomness a future decrypt needs.
Decrypt a JSON package back to plaintext
Decryption is the symmetric path that consumes the bundle produced above. It assumes the package was not modified between machines and that the password reaches you through a channel separate from the bundle itself.
- Choose Decrypt, then paste the JSON package into the input area without any edits, reformatting, or character substitutions.
- Type the same password that was used at encryption time, paying attention to whitespace and any UTF-8 characters.
- Run decryption. The tool validates every label and numeric limit, checks the exact salt and IV lengths, confirms minimum ciphertext length, asks the browser to authenticate the package, and only then releases the plaintext when the 128-bit GCM tag verifies.
- If the password is wrong or any byte of the package was changed, the tool reports an authentication failure and never returns partial plaintext.
The strict validation rules are not decorative. Removing the iteration count, normalizing a base64url field to padded Base64, swapping a character with a visually similar lookalike, or inserting a field that the format does not recognize will all be flagged before any key derivation runs. That keeps a corrupted or tampered package from quietly producing a wrong answer and gives you a clean signal to re-check the transfer.
Inside the JSON package: fields, encoding, and validation
The package layout is declared in the JSON itself, so the four cryptographic ingredients and four supporting fields are always named explicitly. The table below shows what a caller can rely on and how each value is encoded.
| Field | Meaning | Encoding and limits |
|---|---|---|
| v | Format version | Integer, currently 1 |
| kdf | Key derivation function | String "PBKDF2-SHA-256" |
| iter | PBKDF2 iteration count | Integer, 210000 |
| cipher | Cipher identity | String "AES-256-GCM" |
| salt | Random password salt | Base64url, 16 bytes (unpadded, per RFC 4648) |
| iv | Initialization vector | Base64url, 12 bytes, fresh per encryption |
| ct | Authenticated ciphertext + 128-bit GCM tag | Base64url, plaintext bytes followed by the tag |
Decryption reads those fields in order, checks the labels and the numeric limits, and only then lets the Web Crypto API authenticate and unlock the content. The cipher mode and the iteration count are both standardized — AES-GCM is defined in a NIST publication, and the Web Crypto primitives follow the W3C specification for browser-level cryptography. The JSON field layout itself, however, is specific to AES Encryption Online; another system can interoperate only if it reproduces the same UTF-8 handling, the same PBKDF2 parameters, the same GCM tag placement, the same base64url encoding, and the same field names. For a deeper walk-through that extends this same workflow to longer messages or repeated exchanges, see Encrypt and Decrypt Text with AES-256 Online in Your Browser.
Password length, PBKDF2, and what they really buy you
Every value in the JSON package except the password is openly visible. The salt, the IV, and the iteration count are not secrets because their role is uniqueness and key stretching rather than secrecy. What gives the package its strength is the same thing that protects every well-built AES workflow: a high-entropy passphrase processed through a deliberately expensive key derivation. The interface refuses anything shorter than 12 UTF-8 bytes, and the underlying PBKDF2-SHA-256 work factor is fixed at 210,000 iterations to make each guess expensive enough to discourage casual attacks.
Those controls do not turn a weak password into a strong one. A short, reused, leaked, or predictable passphrase remains weak no matter how many iterations you throw at it, because the iteration count slows guessing by a constant factor while password entropy scales the work for an attacker exponentially. The honest rule is the boring one: generate a unique passphrase from a trusted password manager, treat that passphrase as you would any other root secret, and never paste the package and the password into the same chat window, ticket, or document.
The visible randomness is not a vulnerability either. AES-GCM only requires that a given initialization vector be unique for a given key, so generating a fresh random IV every run is exactly the property that prevents two packages under the same password from sharing any useful equality signal. If you ever see the same package bytes twice across two runs, something has gone wrong with the randomness source, not with the cryptography.
What this tool deliberately does not do
A free browser page is not an enterprise key-management system, and it is worth saying so plainly. AES Encryption Online does not store your password, derive recovery keys, escrow secrets, or sync your history across devices. There is no account, no backup, and no operator who can unlock a package on your behalf. The cryptographic boundary of the tool ends at the Web Crypto API inside your current tab; clipboard managers, browser extensions, screen capture, shared computers, and the destination where you paste the package all sit outside that boundary.
That is why the workflow above insists on a separate secure channel for the password and recommends closing the tab when the device is no longer trusted. It is also why the tool is best used for small text snippets, demonstrations, controlled exchanges between known parties, and compatibility experiments rather than as a substitute for reviewed application-level cryptographic design. For any of those larger tasks, the right answer is a system that has been audited for the deployment you actually need.
If you want a cross-check that matches the standards cited here, the underlying AES-GCM behavior is defined in NIST SP 800-38D and the browser-level implementation follows the W3C Web Cryptography specification. The tool itself was checked against the NIST AES-GCM vectors, including an empty-plaintext authentication case and a full zero-block case, which is enough to confirm that defined transformations and package invariants behave as expected without claiming anything about your password or your device.
Related reading: How to Do Binary to Text Conversion in Your Browser.