AES Encryption Online is a browser-based tool that turns plaintext into an AES-256-GCM encrypted JSON package using a password of at least 12 UTF-8 bytes, with PBKDF2-SHA-256 key derivation at 210,000 iterations. The whole operation runs locally through the Web Cryptography API: nothing is uploaded, and the password, derived key, and decrypted output stay on the current page. For a beginner, the practical takeaway is that you type a message and a password, copy a single text package, and share that package with someone who can open it again with the same password.
The rest of this guide walks through what the package actually contains, why AES-256-GCM is the right mode to start with, the exact encrypt and decrypt steps, the mistakes beginners most often make, and the boundaries of what this kind of browser-side tool can and cannot do for you.
What AES Encryption Online Actually Produces
When you click Encrypt, the tool takes your plaintext and your password and produces a single JSON object — not a binary file, not a streamed blob, just one structured text package. Inside that package sit the parameters needed to reproduce the exact same key and to decrypt the same bytes later. The cryptographic ingredients are standardized; the surrounding field layout is specific to this tool.
The package is built around AES with a 256-bit key, run in Galois/Counter Mode (GCM). GCM is an authenticated mode, which means each package carries a 128-bit authentication tag that lets the decrypting side confirm that the bytes were not modified and that the password was correct. Without that tag, an attacker could flip ciphertext bits and the recipient would silently read garbage; with the tag, the receiver is told authentication failed before any partial plaintext is shown.
Here is what the JSON package contains and what each field means:
| Field | Purpose | Notes |
|---|---|---|
| version | Format identifier | Always 1 for this tool |
| cipher | Algorithm label | AES-256-GCM |
| kdf | Key derivation label | PBKDF2-SHA-256 |
| iterations | PBKDF2 work factor | 210,000 |
| salt | Random salt for PBKDF2 | 16 bytes, base64url, not secret |
| iv | Random initialization vector | 12 bytes, base64url, not secret |
| ciphertext | Authenticated ciphertext + 128-bit GCM tag | base64url, must remain unchanged |
The salt and IV appear in plain text inside the package, and that is intentional. Their job is uniqueness, not secrecy. The salt changes the derived key so two runs of the same password produce different keys. The IV changes the ciphertext under the same key so two runs of the same plaintext produce different packages. The only secret in the system is the password, which is never written into the output.
Why AES-256-GCM Is the Safe Default for Beginners
AES itself is a block cipher — a permutation of 128-bit blocks keyed by your secret. "Mode" describes how the cipher is applied across a message longer than one block. AES Encryption Online picks GCM because GCM combines confidentiality with authenticity in a single primitive. The 256-bit key gives AES its wide security margin, while GCM's 128-bit tag stops an attacker from silently swapping ciphertext blocks.
Beginners often reach for tools that advertise "AES encryption" without naming the mode. That single missing word changes the threat model entirely. The table below highlights the contrast at a practical level:
| Property | AES-256-GCM (this tool) | Unauthenticated modes (ECB/CBC/CTR) |
|---|---|---|
| Confidentiality | Yes | Yes |
| Tamper detection | Built-in 128-bit tag | Requires a separate MAC |
| Reaction to wrong password | Authentication failure, no plaintext shown | Decryption still produces bytes (often garbage) |
| Determinism risk | Eliminated by fresh random IV | Same plaintext and key can leak equality |
If you ever see a beginner guide recommending ECB for simplicity, treat it as a red flag. ECB encrypts each block independently, so identical plaintext blocks become identical ciphertext blocks, and patterns show through the encryption. GCM, by contrast, mixes the IV into every block.
Encrypt Your First Message Step by Step
Open AES Encryption Online in a browser that supports the Web Cryptography API (any current Chromium, Firefox, or Safari build). You will see two modes: Encrypt and Decrypt. Encryption is the right starting point.
- Choose Encrypt.
- Type or paste the plaintext you want to protect into the input area. The plaintext stays on the current page.
- Enter a unique password. The interface enforces at least 12 UTF-8 bytes — meaning 12 characters that the browser will encode as UTF-8, which is essentially any text you can type. A passphrase from a password manager, for example four unrelated words plus a number, comfortably clears that bar and resists guessing far better.
- Click the Encrypt action. The tool derives a non-exportable 256-bit AES key with PBKDF2-SHA-256 over 210,000 iterations, generates a fresh 16-byte salt and a fresh 12-byte IV, runs AES-GCM, and produces the JSON package.
- Copy the complete JSON package verbatim. Do not normalize whitespace, reorder fields, swap to standard Base64, or strip quotes.
- Send the package to your recipient over your usual channel and the password over a different one — for example, the package by email and the password by phone, or the package in a chat and the password in a separate one-time message service.
That last point matters more than any parameter. Cryptography protects a message only as well as the weakest link in the chain, and using the same channel for both turns the password into an easy target for anyone who reads the package.
Decrypt a Package You Received
When the recipient — or future-you on another device — opens the JSON, the decryption side is symmetric. The tool does the same PBKDF2 work, but with the salt from the package instead of generating a new one.
- Choose Decrypt.
- Paste the complete, unchanged JSON package. The tool validates the labels, numeric limits, exact salt length of 16 bytes, exact IV length of 12 bytes, minimum ciphertext length, and the base64url syntax before it ever calls the Web Crypto decryption routine.
- Enter the same password that was used during encryption.
- Click Decrypt. Web Crypto authenticates the ciphertext against the 128-bit GCM tag and, only if everything checks out, reveals the plaintext.
If the password is wrong, or if even one byte of the package was altered in transit, Web Crypto raises an authentication failure. The tool does not surface a partial plaintext, a best-effort guess, or a CRC-style remainder; the only response is that decryption was refused. Treat that refusal as a signal to recheck the password first and the package second.
Mistakes Beginners Make with AES Packages
AES-GCM with PBKDF2 is a strong primitive combination, but primitives do not save you from workflow mistakes. These are the patterns the tool's own documentation flags as the most common pitfalls.
- Short or reused passwords. The 12-byte minimum exists to nudge users away from single words, but a 12-character guessable phrase is not actually safe. Use a unique high-entropy passphrase generated by a tool like the Password Generator and never reuse it between packages.
- Editing the JSON package. Prettifying the JSON, fixing Base64 by adding padding, or removing what looks like an unnecessary field all break validation. The format is specific to this tool and must travel unchanged. Per NIST SP 800-38D, GCM expects exact IV length and tag placement; the tool enforces both before any decryption attempt.
- Sending package and password together. Emailing both, pasting both into the same chat, or storing both in the same cloud folder collapses the entire protection into a single point of compromise.
- Trusting the browser tab beyond its boundary. Browser extensions, clipboard managers, screen capture, and shared computers all sit outside the cryptographic boundary. Clear sensitive content from the page and close the tab when the surrounding device is not trusted.
- Treating the tool as a vault. It is built for small text snippets, demonstrations, controlled exchanges, and compatibility experiments. It is not a managed key-management service, encrypted backup system, or substitute for reviewed application-level cryptographic design.
Where AES Encryption Online Fits, and Where It Does Not
The honest framing for a beginner is that AES Encryption Online is a teaching and exchange tool, not a vault. Use it when you want to package a secret string, send it to someone who also has the page open, and verify that AES-256-GCM with PBKDF2 produces a portable, validated JSON blob in the browser. The implementation is checked against the NIST AES-GCM test vectors — including the empty-plaintext authentication case and the full zero-block case — so the underlying transformation behaves as the standard says it should. Field encoding follows the base64url variant of RFC 4648, which is why conventional padded Base64 will not round-trip.
Do not use it when you need long-term key custody, file-level encryption, shared team secrets, or recovery guarantees. There is no password reset, no escrow, no audit log, and no server-side backup, because the architecture is deliberately local. The password never leaves your page; the page therefore cannot help you recover it.
For most beginners that tradeoff is the right one: you see every parameter, you control every step, and the worst-case failure mode is that you forget the password and have to send a new package — a clean, understandable outcome rather than a silent cryptographic mistake.