AES-256-GCM is an authenticated symmetric cipher that encrypts text with a 256-bit key while attaching a 128-bit authentication tag, so any wrong key or tampered byte causes decryption to fail instead of producing a corrupted but readable result. Online tools that advertise AES-GCM wrap those primitives in a portable package you can copy, send, and later open with the same password. The AES Encryption Online tool on Lizely follows that pattern: you type plaintext, choose a passphrase of at least 12 UTF-8 bytes, and the page returns a self-contained JSON document holding a fresh salt, a fresh 12-byte IV, and the base64url ciphertext with the GCM tag appended. To reverse the process, you paste that package back into the page and supply the same password; the tool re-derives the key, runs the same Web Crypto primitive, and prints the original text only if the authentication tag matches. Every step runs in your browser tab through the Web Crypto API, so the password and the plaintext never leave the device you are using right now.
Why AES-256-GCM suits online text exchange
AES-256 is the 256-bit key variant of the Advanced Encryption Standard block cipher. Galois/Counter Mode (GCM) layers an authentication tag on top of that cipher so every encrypted byte is tied to a 128-bit fingerprint derived from the key, the IV, the ciphertext, and any associated data. When a recipient decrypts, Web Crypto re-computes that fingerprint and refuses to release any plaintext if a single bit has been changed.
For online workflows this pairing matters because two things go wrong repeatedly with non-authenticated modes: the wrong key silently produces garbage that looks like text, and a tampered block slips through unnoticed. GCM collapses both failure modes into one hard "authentication failed" response, which is exactly the behaviour an online tool should expose to a user who pastes a package from an unknown channel.
The tool also fits a third practical need. AES-GCM is the AEAD construction that the W3C Web Cryptography Level 2 specification calls out by name, so a page can run the cipher through the standard Web Crypto primitives without bundling a custom implementation. That keeps the JavaScript surface small and avoids the kind of subtle mistakes that show up in hand-rolled crypto.
Anatomy of the JSON package the tool produces
Encryption does not return a raw ciphertext blob. It returns a JSON object designed to be copied, sent over chat, saved to disk, or stored in a note. The fields are explicit so a reviewer can audit the construction.
| Field | Type | Purpose |
|---|---|---|
| v | integer | Package version, currently 1 |
| alg | string | Cipher label, AES-256-GCM |
| kdf | string | Key derivation function, PBKDF2-SHA-256 |
| iter | integer | PBKDF2 iteration count, 210000 |
| salt | base64url | 16-byte random salt, not secret |
| iv | base64url | 12-byte random initialization vector, not secret |
| ct | base64url | Authenticated ciphertext with the 128-bit GCM tag appended |
The salt, IV, and ciphertext are encoded with unpadded base64url per RFC 4648. Validation on the decrypt path checks the labels, numeric limits, field syntax, exact salt and IV lengths, and minimum ciphertext length before Web Crypto is asked to authenticate and decrypt. That gate is what rejects hand-edited or truncated packages before any key material is exposed.
The format is specific to this tool. The cryptographic primitives are standardized, but the surrounding JSON layout 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, and base64url encoding. Keeping the whole package unchanged is the simplest rule, which is why the encrypt output and the decrypt input must match byte for byte.
Encrypt text with AES-256-GCM in your browser
The encrypt side of AES Encryption Online takes plaintext and a password and turns them into a JSON package in a few steps.
- Open the AES Encryption Online page and confirm the Encrypt tab is selected.
- Paste or type the plaintext you want to protect into the input area. The tool accepts any UTF-8 text, including emoji and accented characters.
- Enter a unique password. The interface enforces at least 12 UTF-8 bytes and accepts longer passphrases, which is the minimum bar the tool requires to push back on weak choices.
- Click the Encrypt button. The page generates a fresh 16-byte salt and a fresh 12-byte IV, derives a 256-bit AES key with PBKDF2-SHA-256 at 210,000 iterations, then runs AES-GCM through the Web Crypto API and captures the 128-bit tag.
- Copy the complete JSON package from the output area. Treat the whole block as one atomic artifact; do not delete fields or reformat it.
- Send the package through any convenient channel — chat, email, ticket — and deliver the password through a different secure channel such as a phone call or a password manager share link.
The plaintext, password, derived key, and final result all stay inside the current tab. Nothing is uploaded, so the only copy of the password is the one you keep yourself.
Open a JSON package and recover the original text
Decryption mirrors encryption, but with stricter validation, because a single modified field would otherwise produce misleading output. The typical flow looks like this:
- Switch the tool to Decrypt and paste the unchanged package into the input area.
- Enter the same password that produced the package. The same UTF-8 bytes must arrive at the same PBKDF2 configuration or the derived key will not match.
- Click Decrypt. The page re-derives the key with the stored salt and the stored iteration count, then asks Web Crypto to authenticate and decrypt with the stored IV and ciphertext.
- Read the recovered plaintext if the tag matches. If authentication fails, the tool reports the failure and returns no partial plaintext, which is the GCM guarantee that prevents silent garbage from reaching the user.
Because the salt and IV travel inside the package, decryption is fully portable: any device with the same tool and the right password can open the document, regardless of where it was originally encrypted.
What AES-GCM guarantees, and what it cannot
GCM is a small AEAD construction, and its guarantees line up cleanly with the way this tool uses it.
| Property | What AES-256-GCM provides |
|---|---|
| Confidentiality | Plaintext is hidden from anyone who does not hold the password |
| Integrity | Any modification to the ciphertext or tag causes decryption to fail |
| Authenticity | The 128-bit tag binds the ciphertext to the key that produced it |
| Freshness | A new random salt and IV on every run, so identical plaintext plus identical password still produces a different package |
| Replay safety | Not provided — an attacker who captures a valid package can replay it to anyone who still trusts it |
The same row that promises integrity is also the row that exposes weak passwords. PBKDF2-SHA-256 raises the cost of brute-forcing the key from a guessed password by stretching a single guess through 210,000 SHA-256 rounds, but it cannot turn a short, reused, leaked, or predictable password into a strong secret. A unique high-entropy passphrase from a trusted password manager is what gives the construction something to defend. The AES-256 Encryption: Inside an Authenticated GCM Package guide walks through the same guarantees in more depth if you want a fuller tour.
Operational limits to keep in mind
The page is built for small text snippets, demonstrations, controlled exchanges, and compatibility experiments. It is not a managed vault, enterprise key management service, encrypted backup system, or substitute for reviewed application-level cryptographic design.
Several threats sit outside the cryptographic boundary. Browser extensions with content-script access can read both the plaintext and the password while the tab is open. Clipboard managers keep copies of the package after you copy it. Shared computers, screen capture, and copied package destinations all fall outside what AES-GCM can protect. Clearing sensitive content and closing the tab is the practical mitigation when the surrounding device is not trusted.
There is also no password recovery, escrow, account backup, or server-side key management. If the password is lost, the package is unreadable forever, regardless of how strong the cryptography was. Repeat encryption of the same text under the same password intentionally produces different packages because the salt and IV are randomized, which is the desired property against equality-based traffic analysis. The implementation is checked against the test vectors described in the NIST SP 800-38D GCM publication, so the transformations match the standard, but those checks certify the cipher and the package layout, not the browser, the device, the password choice, or the broader workflow around them.
Related reading: AES Encryption Online: Encrypted Text as a JSON Package.