AES-256 encryption combines the AES block cipher with a 256-bit secret key, the Galois/Counter Mode (GCM) authenticated mode, and a PBKDF2-derived key to turn any plaintext string into a single self-contained JSON package that can travel by email, chat, or file without revealing the original bytes. The 256 in the name is the secret-key length. AES itself is the block cipher standardized by the U.S. National Institute of Standards and Technology, processing 128-bit blocks at a time. With a 256-bit key, AES runs 14 rounds of substitution, permutation, and mixing, the configuration that the original FIPS 197 publication reserves for the highest classification levels. Galois/Counter Mode layers authenticated encryption on top of that block cipher and returns a single ciphertext blob that already includes a 128-bit authentication tag, so any modification to the package, or any wrong password, fails before any plaintext is shown. The package declares the algorithm, the key derivation parameters, the salt, the initialization vector, and the authenticated ciphertext as base64url fields — everything a recipient needs to reproduce the same 256-bit key and verify the result.
What AES-256 Encryption Actually Does
An AES-256 encryption operation accepts a password and a plaintext string, then returns a package that only the same password can unlock. The math behind it is the AES block cipher with a 256-bit secret key, applied through GCM, a mode that combines confidentiality with a built-in integrity check. Under the hood, the password is converted to UTF-8 bytes and stretched into a 256-bit key with PBKDF2-SHA-256; that key is then handed to AES-GCM along with a fresh 12-byte initialization vector and the plaintext. The output is one ciphertext blob that already contains the 128-bit GCM authentication tag appended to the end.
What makes the 256-bit key size special is the size of the search space an attacker would have to brute-force. A 256-bit key has 2^256 possible values, a number so large that no classical computer, and no quantum computer under currently published proposals, can enumerate it within any meaningful time frame. That is why AES-256 is recommended for protecting data classified at the highest levels, including government and financial workloads. AES-128 and AES-192 share the same algorithm with fewer rounds; they remain secure for nearly every practical purpose, but the 256-bit variant is the conservative default for long-term archives.
AES Key Sizes at a Glance
AES accepts three key sizes against the same 128-bit block. The table below summarizes the values that FIPS 197 and NIST SP 800-38D define for each variant.
| Variant | Key size (bits) | Rounds | Block size | Recommended GCM IV |
|---|---|---|---|---|
| AES-128 | 128 | 10 | 128 bits | 96 bits (12 bytes) |
| AES-192 | 192 | 12 | 128 bits | 96 bits (12 bytes) |
| AES-256 | 256 | 14 | 128 bits | 96 bits (12 bytes) |
The variant used by the tool is the rightmost row: a 256-bit key, fourteen rounds, and a 12-byte IV. Choosing AES-256 over the smaller variants does not change the package format or the GCM tag length; it simply raises the brute-force cost of guessing the password-derived key.
Anatomy of the Authenticated JSON Package
Each encryption produces one JSON object. The fields declare which algorithm, key derivation, and iteration count were used, then carry the salt, initialization vector, and ciphertext as base64url strings. Stripped of whitespace the structure looks like this:
"version": 1, "alg": "AES-256-GCM", "kdf": "PBKDF2-SHA-256", "iter": 210000, "salt": "<base64url>", "iv": "<base64url>", "ct": "<base64url>"
The salt field is exactly 16 raw bytes (16 × 8 = 128 bits), base64url-encoded without padding; the IV field is exactly 12 raw bytes (12 × 8 = 96 bits); and the ciphertext field carries the encrypted bytes plus the 128-bit GCM authentication tag appended to the end, the layout that the W3C Web Cryptography specification documents for AES-GCM outputs. The Web Cryptography Level 2 specification is the reference the tool follows for key import, derivation, encryption, and decryption.
Because the package is the entire protected payload, it must be transmitted and stored exactly as produced. Removing a field, normalizing whitespace into padded standard Base64, or trimming the tag from the ciphertext will all cause the decryption step to fail its strict validation. Treat the package as opaque text and never edit it.
From Password to 256-bit Key
A password typed into the page is not the key that AES uses. The tool runs PBKDF2-SHA-256 with the supplied password (UTF-8 encoded) and the random 16-byte salt, repeating the SHA-256-based derivation 210,000 times to produce a non-exportable 256-bit AES key. That iteration count is high enough to make each password guess expensive on commodity hardware, which is exactly the role PBKDF2 plays in the system.
The salt does not need to be secret. Its job is to ensure that two users who happen to choose the same password still end up with different derived keys, and to prevent an attacker from amortizing one guess across many packages. The salt is therefore stored in the package itself, alongside the IV, where it must be present for decryption but is safe to expose.
PBKDF2 cannot rescue a weak password. A short, reused, or predictable secret is still the easiest thing to break in this system, so the tool requires at least 12 UTF-8 bytes and accepts longer passphrases. Pulling a unique high-entropy passphrase from a trusted password manager is the practical way to make AES-256 actually do its job.
How to Encrypt and Decrypt Text in Your Browser
Open the AES Encryption Online page. The encryption and decryption modes sit in the same interface, so the same tool covers both halves of the workflow.
- Choose Encrypt, enter the plaintext in the message field, and type a unique password of at least 12 UTF-8 bytes.
- Run the encryption. The page derives the AES-256 key, encrypts with AES-GCM, and shows the resulting JSON package on screen.
- Copy the entire JSON package unchanged and keep the password in a separate secure channel — never paste them into the same message, ticket, or note.
- To recover the plaintext, switch to Decrypt, paste the exact package back into the input, and enter the same password.
- Run the decryption. If the password and bytes are correct you will see the original plaintext; if anything is wrong the page reports an authentication failure and shows no partial result.
The same flow works in reverse for anyone holding the password and the package. Both runs happen entirely in the browser through the Web Crypto API, and the plaintext, password, derived key, and decrypted result all stay on the current page.
Why GCM Authentication Matters
Authentication is the half of AES-GCM that most casual explanations skip. AES by itself only provides confidentiality, and any wrong key will still decrypt the bytes — they will just decrypt to garbage. GCM adds a 128-bit tag computed over both the ciphertext and the IV, and it ties that tag directly to the key. Decrypting with a wrong password fails to reproduce the tag, so the page stops and reports an authentication failure rather than returning a misleading string.
The same tag is what catches tampering. If a single byte of the ciphertext, the IV, or the salt is changed between sender and recipient, the recomputed tag will not match, and decryption will be rejected before any plaintext is displayed. That is the property that turns the JSON package into a verifiable receipt rather than a fragile ciphertext blob, and it is why the package format reserves space for the tag at the end of the ct field.
For users who want to add a separate keyed digest on top of AES-GCM, the related HMAC generation guide walks through generating SHA-256, SHA-384, and SHA-512 tags with explicit key control. AES-GCM's built-in tag covers the same threat model for confidentiality-and-integrity in one step, so layering HMAC on top is usually unnecessary unless an application demands an independent primitive.
Practical Limits and What This Tool Does Not Do
The boundary of this tool is the browser tab it runs in. Clipboard managers, browser extensions, screenshots, shared computers, and the destination you paste the package into all sit outside AES-256 and can still leak the data, so clear the page and close the tab when the surrounding device is not trusted.
There is no password recovery, no escrow, no account, and no server-side key management. If the password is lost, the package cannot be opened, even by the operator of the site. Treat the password with the same care you would treat the plaintext itself.
This page is sized for small text snippets, demonstrations, controlled exchanges, and compatibility experiments. It is not a managed vault, an enterprise key-management service, or an encrypted backup system. For larger files, key rotation, or audited application-level cryptography, you need reviewed infrastructure rather than a single browser form. The tool's own implementation has been checked against NIST AES-GCM vectors, including the empty plaintext authentication case and a full zero-block encryption case, and the base64url fields follow RFC 4648 — proving the defined transformations and package invariants, not certifying the device or the password choice behind them.