AES Encryption Online turns an entire paste, document, or script — whatever the bulk of text you need to protect — into a single self-contained JSON package that opens only with the original password. The package uses AES with a 256-bit key in Galois/Counter Mode, a fresh 16-byte random salt, a fresh 12-byte random initialization vector, PBKDF2-SHA-256 key derivation with 210,000 iterations, and a 128-bit GCM authentication tag. Plaintext, password, derived key, and decrypted output never leave the current page; the Web Crypto API does the work and nothing is sent to Lizely. Because AES-GCM also authenticates the ciphertext, decryption refuses to return a partial plaintext when the password is wrong or any byte in the package was modified.
What "bulk" means inside AES Encryption Online
When readers search for bulk AES encryption online, they usually want to protect a long chunk of text in one pass rather than encrypt it line by line. AES Encryption Online supports that workflow by accepting the full plaintext into a single textarea and producing a single JSON package as output. There is no row counter, batch list, or queue: one input, one password, one package. The package is portable because the salt, IV, ciphertext, tag, algorithm labels, and PBKDF2 iteration count are all embedded in the JSON itself, so the receiver can hand the file to the tool on any modern browser and recover the original text with the password.
This design is what makes the tool practical for whole documents, configuration dumps, secret snippets, and small backups. You paste, you choose a password, you copy the package. You never have to manage a key file, an IV file, or a separate integrity file — the format folds those pieces into one base64url block of authenticated ciphertext.
Anatomy of the JSON package
The package is JSON, not a custom binary file. Every field has a defined role and the tool validates them before decryption. The table below lists each label and what it carries so you can confirm what is stored openly and what must remain secret.
| Field | Content | Purpose |
|---|---|---|
| version | Integer, currently 1 | Format identifier so future revisions stay readable |
| cipher | "AES-256-GCM" | Selected authenticated cipher |
| kdf | "PBKDF2-SHA-256" | Key derivation function used on the password |
| iterations | 210000 | PBKDF2 iteration count |
| salt | base64url, 16 bytes | Random salt, not secret, mixed into key derivation |
| iv | base64url, 12 bytes | Random initialization vector, not secret |
| ciphertext | base64url, ciphertext with appended 128-bit GCM tag | Encrypted bytes plus authentication tag |
The salt and IV are visible on purpose: their job is uniqueness, not secrecy. The password is the only secret, and the tool never embeds it in the package. The 128-bit GCM tag at the end of the ciphertext field is what lets the Web Crypto API reject a tampered or mistyped-password package without leaking partial plaintext.
Encrypt and decrypt a bulk package step by step
The procedure below covers the full round trip: sealing a large paste into a portable package and reopening it on the other side. Treat the JSON output like a sealed envelope — keep it intact and send the password through a different channel.
- Open AES Encryption Online and choose Encrypt.
- Paste the full bulk text — a long email, a settings file, a script — into the plaintext box.
- Enter a unique password of at least 12 UTF-8 bytes. A high-entropy passphrase from a trusted password manager is strongly recommended for any meaningful protection.
- Run the encryption. The tool derives a non-exportable 256-bit AES key with PBKDF2-SHA-256 using a fresh random salt and 210,000 iterations, then encrypts with AES-GCM using a fresh 12-byte IV and a 128-bit tag.
- Copy the entire JSON package exactly as produced. Do not reformat, beautify, strip whitespace inside base64url strings, or swap unpadded base64url for padded Base64.
- Send the JSON package to the recipient through one channel (email attachment, cloud doc, ticket attachment) and the password through a separate secure channel (Signal, in person, a second device).
- To recover the text, the recipient opens the same tool, chooses Decrypt, pastes the unchanged package, and enters the password.
- Run decryption. If the password matches and every byte of the package is intact, the original bulk text appears. If anything was altered, the tool reports an authentication failure and never reveals what the package contained.
Why the same bulk input produces different output each run
If you encrypt the same long document twice with the same password, the two JSON packages will look completely different. That is intentional. AES Encryption Online generates a fresh 16-byte salt and a fresh 12-byte IV for every run, then mixes the salt into PBKDF2 and the IV into AES-GCM. Two consequences follow. First, the ciphertext bytes differ even when the plaintext is identical, which prevents a passive observer from spotting equality through deterministic output. Second, the salt is stored in the package so decryption can recompute the same key — so the package stays self-contained without any external state.
This design also means you must never reuse an old IV or salt by editing the package. AES-GCM requires an IV that is unique for a given key, and the tool guarantees that uniqueness by generating a new random value rather than letting users paste one in. The random values are stored openly because their purpose is uniqueness and key derivation, not secrecy.
What stays inside the cryptographic boundary
A useful way to think about the tool is to separate the cryptography from the surrounding device. The cryptographic boundary covers the AES-256-GCM transform, the PBKDF2-SHA-256 derivation, the 128-bit authentication tag, the version-1 JSON layout, and the base64url encoding of the salt, IV, and ciphertext-plus-tag. That boundary is checked against the NIST AES-GCM test vectors — including an empty plaintext authentication case and a full zero-block encryption case — and against the RFC 4648 base64url fixtures, per the W3C Web Cryptography Level 2 specification. Those checks prove the defined transformations and package invariants; they do not certify the browser, the device, the password choice, or the broader workflow.
The tool's own product contract is explicit on this point. Browser extensions, clipboard managers, screen capture tools, shared computers, and the destinations where the package is pasted all remain outside the cryptographic boundary. Clear sensitive content and close the tab when the surrounding device is not trusted. Use the page 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.
Practical limits for a bulk paste
Two limits shape how large a "bulk" package can be in this tool. The first is the password rule: the interface requires at least 12 UTF-8 bytes and accepts longer passphrases. A bulk encryption with a one-character password is not allowed, because short passwords undermine the entire PBKDF2 derivation regardless of how many iterations run. The second limit is the JSON layout itself. The package must use unpadded base64url fields, exact 16-byte salt length, exact 12-byte IV length, and a ciphertext long enough to include the 128-bit GCM tag. Removing a field, normalizing whitespace inside a base64url string, or inserting padded Base64 where base64url is expected makes decryption fail with a validation error before Web Crypto is ever asked to authenticate the bytes.
For very large pastes, also consider the clipboard and the destination. Browser clipboard size caps, email body length limits, ticket attachment quotas, and any logging middleware on the receiving side can truncate or split the package. If you are sealing documents that exceed comfortable paste size, split the input into a small number of named packages rather than chaining them together — each package is independent and can be opened on its own.
Picking a password that holds up at bulk scale
PBKDF2-SHA-256 with 210,000 iterations raises the cost of guessing the password, but it cannot rescue a short, reused, leaked, or predictable passphrase. For a bulk document that you may not open again for months or may hand to a colleague, generate a fresh high-entropy passphrase in a password generator you trust, store it in a password manager, and never paste it into the same channel as the package. The salt and IV that the package exposes do not weaken the password; they only make the key derivation and the AES-GCM nonce unique.
Finally, keep the whole package unchanged between sender and recipient. Treat the JSON as an opaque envelope: do not normalize line endings, do not convert base64url to standard Base64, and do not strip fields. AES-GCM authentication depends on the exact bytes being present, so a single character of cosmetic reformatting can flip a working package into an authentication failure that reveals nothing about the original plaintext.