AES Encryption Online turns a piece of plain text and a password into a self-contained, authenticated AES-256-GCM JSON package using the Web Crypto API inside the current browser tab, with no network submission of the password, the derived key, or the decrypted result. The protection comes from the Advanced Encryption Standard run with a 256-bit key in Galois/Counter Mode, paired with PBKDF2-SHA-256 key derivation at 210,000 iterations, a fresh 16-byte random salt, and a fresh 12-byte random initialization vector for every run. The resulting package carries a 128-bit authentication tag so that any tampered byte, any changed field, or any wrong password causes decryption to fail before plaintext is revealed. Because both operations execute locally, the tool is best understood as a controlled, transparent envelope for small text snippets rather than as a hosted vault, account system, or enterprise key-management service.
What AES-256-GCM Online Encryption Actually Does
The Advanced Encryption Standard is the symmetric block cipher standardized in NIST FIPS 197 and widely used to protect HTTPS traffic, encrypted filesystems, disk images, and database columns. Symmetric means the same secret key is used to encrypt and to decrypt, so the entire security of the scheme rests on keeping that key private. AES supports 128, 192, and 256-bit keys; AES Encryption Online always uses the 256-bit variant, which gives the largest internal key schedule and the highest cost for any brute-force attempt against a guessed password.
Block ciphers cannot operate safely on arbitrary input on their own, so they are wrapped in a mode of operation. AES Encryption Online uses Galois/Counter Mode (GCM), an authenticated mode standardized in NIST SP 800-38D. GCM produces both ciphertext and a 128-bit authentication tag computed over the encrypted bytes and any associated metadata. The tag lets the decrypting side verify that nothing was changed after encryption, so a wrong password, a flipped bit in the package, or a removed field all produce a hard authentication failure instead of silently corrupted plaintext.
Because the same password cannot be fed directly to AES, the tool first runs it through PBKDF2 with SHA-256 and 210,000 iterations, mixing in a random 16-byte salt that is unique per encryption. PBKDF2 raises the cost of guessing the password for an attacker who steals a package, but it cannot rescue a short, reused, leaked, or predictable password. The minimum required length is 12 UTF-8 bytes, and a unique high-entropy passphrase generated by a trusted password manager remains the single strongest control on the entire workflow.
Inside the AES Encryption Online JSON Package
The output of an encryption is a self-contained JSON document. Every field has a defined purpose, and the strict layout is specific to this tool. Other systems can read the package only if they reproduce the same UTF-8 handling, PBKDF2 parameters, AES-GCM tag placement, base64url encoding, and field names. Removing a field, switching base64url to padded base64, or rearranging the ciphertext and tag will break validation before the cipher is even consulted.
| Field | Purpose | Encoding |
|---|---|---|
| version | Format identifier, currently 1 | Integer |
| cipher | Algorithm label, AES-256-GCM | String |
| kdf | Key derivation function, PBKDF2-SHA-256 | String |
| iterations | PBKDF2 work factor, 210000 | Integer |
| salt | Random 16-byte salt for PBKDF2 | Base64url, unpadded |
| iv | Random 12-byte initialization vector | Base64url, unpadded |
| ciphertext | Encrypted bytes with appended 128-bit GCM tag | Base64url, unpadded |
The salt and IV are stored openly because their job is uniqueness, not secrecy. AES-GCM is catastrophically weak if the same key and IV combination is ever reused, which is why the tool generates a fresh random value for every run instead of asking the user to invent one. Editing the package to swap in an older salt, IV, or ciphertext breaks the package and is never a valid recovery move.
Encrypt Text Online with AES-256-GCM
Use the AES Encryption Online tool when you want a portable, password-protected text package you can paste into chat, commit to a repository, or store alongside other files. Follow these steps for a clean encryption.
- Choose Encrypt, paste or type the plaintext into the input field, and enter a unique password of at least 12 UTF-8 bytes. Longer passphrases from a trusted password manager are strongly recommended.
- Run the encryption. The browser generates a fresh random 16-byte salt and 12-byte IV, derives a non-exportable AES-256 key with PBKDF2-SHA-256 at 210,000 iterations, and encrypts with AES-GCM using a 128-bit tag.
- Copy the complete JSON package from the output area. Do not edit, reformat, or re-encode any field; the base64url strings, labels, and numbers must remain exactly as produced.
- Send the package and the password through separate channels. The package itself is not secret, but the password is, and the two must never be pasted into the same message, ticket, or file.
- Clear sensitive content from the page and close the tab once the transfer is finished, especially on shared or untrusted devices.
Decrypt a Package and Handle Authentication Failures
Decryption mirrors encryption but in reverse. Choose Decrypt, paste the unchanged JSON package, enter the same password, and run the operation. The tool first validates the labels, numeric limits, field syntax, exact salt and IV lengths, and minimum ciphertext length. Only after those structural checks pass does it ask the Web Crypto API to authenticate and decrypt the content.
If the password is wrong, or if any byte of the package has been altered, the GCM tag check fails and the tool reports an authentication failure without exposing partial plaintext. This is the safe outcome: a successful decrypt is the only signal that the package and the password both match the original encryption. A package that decodes to anything other than your expected plaintext should be treated as compromised.
When a decryption fails, do not try to repair the package by trimming whitespace, converting base64url to padded base64, swapping fields, or reusing an older IV. Every one of those edits changes the bytes that the tag covers and will continue to fail. Instead, request a fresh package from the sender, with a new salt, IV, and ciphertext.
AES-256-GCM Compared With Other Common Modes
Different AES modes make different trade-offs, and understanding the contrast clarifies why this tool chose GCM. The table below compares the modes you are most likely to encounter in cryptographic libraries.
| Mode | Authenticated | IV requirements | Typical use |
|---|---|---|---|
| AES-256-GCM | Yes, 128-bit tag | 12-byte, fresh per key | TLS, encrypted storage, portable packages |
| AES-256-CBC | No, requires separate HMAC | 16-byte, unpredictable | Legacy disk and file formats |
| AES-256-CTR | No, requires separate HMAC | 12-byte, fresh per key | Streaming, disk encryption |
| AES-256-ECB | No | None | Demonstrations only; never for production |
GCM combines encryption and authentication in one pass and returns a clear failure on tampering, which is why the tool's strict package validation plus the GCM tag together give a single, decisive verdict on every decryption attempt.
What Stays Outside the Cryptographic Boundary
The cryptographic boundary ends at the browser tab. Anything that touches the surrounding device, the operating system, or the destination of the package is outside that boundary and can defeat even a perfectly implemented cipher.
- Browser extensions can read the page, the inputs, and the clipboard. Disable or remove them when handling sensitive material.
- Compromised devices, keyloggers, screen capture, and clipboard managers observe plaintext and passwords regardless of how strong the cipher is.
- Shared computers and remote sessions should be treated as hostile. Clear the page and close the tab when finished.
- The package destination matters. Email threads, shared documents, version control commits, and chat logs each come with their own access controls and retention rules.
- Password hygiene is the real ceiling. A unique 20-character passphrase from a password manager is dramatically stronger than a reused 12-character phrase, even with 210,000 PBKDF2 iterations.
The tool is positioned for small text snippets, controlled exchanges, demonstrations, and compatibility experiments. It is not a managed vault, an enterprise key management service, an encrypted backup system, or a substitute for reviewed application-level cryptographic design. Use it for the envelopes it is built to produce, and pair it with the operational discipline that envelope encryption still requires.