AES-256-GCM uses a 256-bit key, a 96-bit IV, and a 128-bit authentication tag, with the key derived from a password through PBKDF2-SHA-256 over 210,000 iterations. This cheat sheet condenses the cipher parameters, JSON package layout, and operational workflow of the AES Encryption Online tool so you can look up a value, run an encryption, or troubleshoot a failed decrypt without rereading the full specification. The tool runs entirely in the current browser tab through the Web Crypto API; the plaintext, password, derived key, and decrypted result stay on the page and are never uploaded to any server. Each encryption requests a fresh 16-byte salt and a fresh 12-byte IV, which is why the same plaintext and password produce a different package every time. Decryption rejects a package whose password is wrong or whose bytes were modified, and reports the failure without revealing any partial plaintext. The sections below collect the numbers, label the JSON fields, walk through the encrypt and decrypt steps, and call out the most common pitfalls so the page works as a quick reference rather than a tutorial.
AES at a Glance: The Numbers That Matter
The cipher parameters used by the AES Encryption Online tool follow the AES-GCM standard published as NIST SP 800-38D and the key derivation primitives defined in the W3C Web Cryptography specification. The table below records the exact values the tool requests, the units they are measured in, and the source standard behind each one. Use it as the first stop whenever you are wiring up an external interop or debugging a failed decrypt, because every other section in this cheat sheet refers back to these constants.
| Parameter | Value | Source or role |
|---|---|---|
| Cipher | AES-256 in Galois/Counter Mode | NIST SP 800-38D |
| Key size | 256 bits | NIST SP 800-38D |
| Block size | 128 bits | NIST SP 800-38D |
| IV size | 96 bits (12 bytes) | NIST SP 800-38D, recommended for GCM |
| Authentication tag | 128 bits | Web Crypto API default |
| KDF | PBKDF2 with HMAC-SHA-256 | PKCS #5, used through Web Crypto |
| Salt size | 128 bits (16 bytes) | Web Crypto API |
| PBKDF2 iterations | 210,000 | Tuning for browser cost |
| Password minimum | 12 UTF-8 bytes | Tool input validation |
| Encoding alphabet | Unpadded base64url | RFC 4648, section 5 |
The JSON Package Layout
The encrypted output is not raw ciphertext; it is a self-describing JSON object that lists the algorithm, parameters, and base64url-encoded fields the recipient needs in order to decrypt. The format is versioned, so a future change can increment the version field without breaking older packages. The table below lists every field that appears in a fresh package, the value or shape it takes, and a short note on why it is there, which lets this section double as a reference card when reading or emitting a package.
| Field | Value or shape | Notes |
|---|---|---|
| v | 1 | Format version. Increment on any breaking change. |
| alg | "AES-256-GCM" | Cipher declaration, matched at decrypt time. |
| kdf | "PBKDF2-SHA-256" | Key derivation function declaration. |
| iter | 210000 | Iteration count used during key derivation. |
| salt | base64url string | 16 random bytes; not secret. |
| iv | base64url string | 12 random bytes; not secret. |
| ct | base64url string | AES-GCM ciphertext concatenated with the 128-bit tag. |
Encrypt and Decrypt with the Online Tool
The workflow below mirrors the operating steps of the AES Encryption Online tool. Keep the JSON package and the password in separate channels so that even if one is leaked the other remains protected, and run a quick sanity check on the output before treating it as the canonical ciphertext.
- Open the AES Encryption Online tool and choose the Encrypt action.
- Type or paste your plaintext into the message field. The tool accepts any UTF-8 string the browser can render, including accents, emoji, and multi-line notes.
- Enter a unique passphrase of at least 12 UTF-8 bytes. Pull it from a trusted password manager rather than reusing an existing string or a memorable phrase.
- Run the encryption. The browser derives a non-exportable 256-bit AES key with PBKDF2-SHA-256, the salt, and 210,000 iterations, then encrypts with AES-GCM using a fresh 12-byte IV and a 128-bit tag.
- Copy the resulting JSON package in full and store it in the destination that will receive the ciphertext, such as a file, a chat message, or an API payload.
- Deliver the password through a separate secure channel such as a password manager share, an out-of-band message, or a verbal exchange. Never paste it into the same place as the package.
- To open the package later, switch the tool to Decrypt, paste the unchanged JSON, enter the same password, and run decryption. If the password is wrong or any byte was modified, authentication fails and no plaintext is returned.
Pitfalls That Break a Decryption
Most failed decryptions are caused by a small set of predictable mistakes. Treat the list below as a quick troubleshooting reference when a package refuses to open, and fix the issue before assuming the cipher itself is broken or that the password has been lost.
- Pasting a padded Base64 string instead of unpadded base64url. The package uses base64url without padding per RFC 4648; converting it to canonical padded Base64 will fail validation before Web Crypto is even called.
- Trimming whitespace is fine, but rewriting field names, dropping a field, or reordering values is not. The strict validation step checks labels, numeric limits, field syntax, and exact salt and IV lengths before authentication is attempted.
- Reusing an old IV or salt to reproduce a package. AES-GCM requires a unique IV per key, so the tool generates a fresh value each run and a reused IV is rejected.
- Choosing a short or reused password. PBKDF2 raises the cost of guessing but cannot turn a leaked or low-entropy passphrase into a strong secret, so the protection floor is set by password quality, not iteration count.
- Pasting the password into the same channel as the package. Once both travel through the same leak, the encryption provides no practical confidentiality, regardless of the cipher underneath.
- Relying on the tool as a managed vault. There is no account, no recovery, and no escrow; lose the password and the package is gone, by design.
When the Online AES Tool Fits and When It Does Not
The AES Encryption Online tool is built for small text snippets, controlled exchanges, demonstrations, and compatibility experiments where both sides have agreed on this specific JSON package format. It fits neatly into situations such as sending a one-off secret over a chat that supports code blocks, attaching a sealed note to a support ticket, comparing behavior against a reference implementation, or teaching how AES-GCM packages are laid out in practice. It also helps when an external system has to reproduce the same output: as long as that system matches the UTF-8 handling, PBKDF2 parameters, AES-GCM tag placement, base64url encoding, and JSON field layout, it can interoperate with packages produced here without any server-side key management.
It does not replace a managed vault, an enterprise key management service, or a reviewed application-level cryptographic design. Browser extensions, compromised devices, clipboard managers, screen capture, and shared computers all sit outside the cryptographic boundary, so sensitive content should be cleared and the tab closed when the surrounding device is not trusted. For at-rest encryption of large files, regulated data, or long-term secrets, use a purpose-built system with audited storage, hardware-backed keys, and a documented recovery procedure. Treat this cheat sheet as a quick lookup reference for the parameters and workflow above, and reach for the underlying NIST and W3C specifications when you need the formal wording for a security review.
If you're weighing options, ASCII Code Converter Cheat Sheet: Quick Decimal Reference covers this in detail.