How much text is "large" for this tool?

The tool treats every input as one plaintext, so "large" is really a workflow question. A few kilobytes feels comfortable, dozens of kilobytes still run in a single AES-GCM encryption, and multi-megabyte texts work as long as the browser can hold the string. There is no internal splitting or tiling.

Will encrypting the same large text twice give the same package?

No. Every run draws a fresh 16-byte salt and a fresh 12-byte IV, so the resulting JSON package is different even when the password and plaintext are identical. That is the intended behavior and it prevents deterministic ciphertext under the same password.

Is there a maximum text size the page accepts?

The page does not publish a hard character ceiling. The practical envelope is set by the browser tab's memory and the input area, not by the cipher. Past that, the package itself becomes large enough that ordinary chat windows or clipboard tools may struggle to round-trip it intact.

Can I send the package by email or paste it into a chat?

Yes, as long as the destination preserves the JSON exactly — no field reordering, no whitespace normalization inside base64url fields, no padded Base64 substitution, and no truncation. The password must travel through a separate, trusted channel.

Does the tool ever send my plaintext, password, or package to a server?

No. Encryption, key derivation, decryption, and validation all run through the browser Web Crypto API. The plaintext, the password, the derived key, and the decrypted result stay in the current page and are not submitted anywhere.

What happens if I lose the password?

The package cannot be opened. There is no password recovery, escrow, account backup, or server-side key management, because no copy of the password leaves the browser. Losing the password means losing access to the package, no matter how large the original text was.

AES Encryption Online for Large Text: Bulk Input Guide

AES Encryption Online wraps large text into one AES-256-GCM JSON package, encrypts it with a 256-bit key derived from your password, and lets you copy the result without uploading a single character. Every run starts with a fresh 16-byte random salt and a fresh 12-byte random initialization vector, processes the password through 210,000 PBKDF2-SHA-256 iterations, and seals the ciphertext plus a 128-bit authentication tag inside a versioned JSON envelope. The whole pipeline runs through the browser Web Crypto API, so the plaintext, the password, the derived key, and the decrypted result stay on the current page. That combination is what makes the tool usable for long passages, configuration blobs, code snippets, API tokens, and other multi-kilobyte inputs that would be awkward to handle with a tool that requires uploads or accounts. Because the JSON package carries the salt, IV, and authenticated ciphertext openly, the recipient only needs the unchanged package text and the matching password to recover the original message — there is no separate key file, no server backup, and no recovery flow.

aes encryption online large text — AES Encryption Online for Large Text: Bulk Input Guide

What Counts as "Large Text" for Browser AES Encryption

For a browser-based cipher, "large text" usually starts where a casual copy-paste starts to feel awkward: a few kilobytes of prose, a multi-page log, a configuration block, a SQL dump, a stack trace, a JSON document, a list of API keys. There is no published character ceiling on the page, but the practical envelope is set by the input area, the device memory available to the JavaScript runtime, and the willingness of the recipient to paste back an entire JSON package without edits.

For most workflows, anything up to roughly 100 KB of UTF-8 text feels comfortable; multi-megabyte inputs work as long as the browser can hold them in a single string, which on a desktop is usually well above the user's reading workload. The crucial point is that the tool does not chunk, split, or stream the input. Whatever you put into the plaintext box becomes the single plaintext of one AES-256-GCM encryption, and the result is one JSON package. There is no internal tiling, no multi-block format, and no reassembly step on the decryption side.

Inside the AES-256-GCM JSON Package

The output is a structured JSON object, not a flat Base64 blob. That choice matters for large text: every byte you typed has to survive the round trip, and a self-describing container makes that easier to verify, copy, and audit.

Field	Type	Purpose
v	integer (1)	Format version, pinned to 1
alg	"AES-256-GCM"	Declared cipher
kdf	"PBKDF2-SHA-256"	Key derivation function
iter	integer (210000)	PBKDF2 iteration count
salt	base64url string	16-byte random salt
iv	base64url string	12-byte random initialization vector
ct	base64url string	Authenticated ciphertext including the 128-bit GCM tag

The fields declare every cryptographic decision the package relies on: the algorithm, the KDF, the iteration count, plus the random values that make each encryption unique. The ct field carries the ciphertext with the GCM tag appended, which is the form Web Crypto returns from subtle.encrypt; that placement is part of the contract, not an arbitrary choice.

Parameter	Value
Cipher	AES-256 in Galois/Counter Mode
Key size	256 bits
Salt	16 bytes, fresh per encryption
IV	12 bytes, fresh per encryption
Authentication tag	128 bits
KDF	PBKDF2-HMAC-SHA-256
PBKDF2 iterations	210,000
Base64 flavor	Unpadded base64url
Processing location	Browser Web Crypto API

Two consequences fall out of this layout for large text. First, the package itself is bigger than the plaintext: the base64url overhead, the JSON envelope, and the appended GCM tag all add bytes, and the tool does not compress the input. Second, because the salt and IV are stored openly, anyone who sees the package knows the algorithm parameters; the only secret is the password. That is the intended design — uniqueness of the random values, not secrecy, is what defeats deterministic ciphertext and key-reuse attacks, as specified in NIST SP 800-38D.

Encrypt a Large Block of Text Step by Step

This workflow covers the full path from a long plaintext in your browser to a self-contained JSON package ready to share.

Open AES Encryption Online in a current Chromium, Firefox, or Safari build. The tool needs the Web Crypto API, which every modern browser ships.
Choose Encrypt. The interface presents a plaintext box and a password field; nothing else needs configuration.
Paste or type the full large text — paragraphs, JSON, log lines, configuration — into the plaintext area. Do not trim or "clean" the text, because every byte becomes part of the AES-GCM plaintext and any change will alter the ciphertext and the tag.
Enter a password of at least 12 UTF-8 bytes. A unique high-entropy passphrase from a trusted password manager is the realistic minimum; PBKDF2 cannot rescue a short, reused, or leaked password.
Run the encryption. The tool generates a fresh 16-byte salt and a fresh 12-byte IV, derives a non-exportable 256-bit AES key through 210,000 PBKDF2-SHA-256 iterations, and produces a 128-bit authentication tag alongside the ciphertext.
Copy the complete JSON package. Make sure no field is dropped, no whitespace inside the base64url strings is altered, and no standard padded Base64 is substituted where base64url is expected.
Send the package through one channel and the password through a separate, trusted channel. The package is safe to read in transit; the password is the only piece that must remain confidential.

For very long inputs, give the page a moment to finish. PBKDF2 at 210,000 iterations is intentionally heavy, and a multi-kilobyte plaintext still expands only to one encryption call, so the dominant wait is the key derivation, not the cipher itself. The result is the entire plaintext, no chunking, packaged as a single JSON object.

Decrypt a Large-Text Package

The decryption path mirrors encryption but with strict validation, which is the part that protects large inputs against tampering.

Choose Decrypt on the same tool.
Paste the entire JSON package exactly as you received it. Do not normalize line endings, do not run it through a JSON pretty-printer that rewrites field order in a non-canonical way, and do not convert base64url strings into padded Base64.
Enter the matching password. A different password, a truncated password, or a password whose UTF-8 form differs from the one the original encryption saw will fail.
Run decryption. The tool checks every label, numeric limit, and field syntax, verifies the salt and IV byte lengths, and confirms that the ciphertext is long enough to contain the 128-bit GCM tag before it calls Web Crypto.
Read the recovered plaintext. If authentication fails, the tool reports a failure and shows no partial plaintext — that is the GCM contract, and it is what stops an attacker from learning whether the first few bytes of a long message decoded correctly.

If validation fails, the usual suspects are whitespace inside a base64url field, a stray equals sign at the end of ct, an old IV pasted back into a new package, or a field that was removed during a manual copy. None of these can be repaired on the decryption side; the encryption must be repeated with a fresh package, which is also why the base64url convention defined in RFC 4648 matters for every byte of the ciphertext field.

Password Rules That Matter for Big Inputs

PBKDF2-SHA-256 at 210,000 iterations raises the cost of guessing, but it does not change the entropy of the password itself. The tool enforces a minimum of 12 UTF-8 bytes, which is a floor against trivially weak inputs, not a guarantee. A passphrase made of several unrelated words from a password manager comfortably clears that bar for any length of plaintext, while a short reused password undermines the encryption no matter how large the package is.

Because the salt is unique per encryption, the same long text encrypted twice with the same password produces two different packages. That is expected, and it is what prevents an observer from recognizing identical plaintexts by comparing ciphertexts. The salt and IV travel in the JSON; they do not need to be secret.

What does need to be secret is the password, and the tool never writes it into the output, never logs it, and never sends it anywhere — the Web Crypto derivation happens inside the browser tab. There is also no recovery, escrow, account backup, or server-side key management, so losing the password means the package cannot be opened. For a long input, that loss is total: every kilobyte of plaintext becomes permanently inaccessible.

Practical Limits and Threats the Tool Does Not Cover

The encryption boundary ends at the Web Crypto call. Several realistic risks live outside that boundary and matter more as inputs get larger.

Browser extensions, clipboard managers, screen capture tools, and shared computers can read the plaintext or the password as you type or copy them, regardless of how strong the underlying cipher is.
File-system destinations and chat services that re-encode attachments can normalize whitespace, wrap long lines, or alter JSON formatting, which corrupts the package even though the visible bytes look similar.
The tool is not a managed vault, an enterprise key management service, or an encrypted backup system; it is a small-text, controlled-exchange utility with a standardized cryptographic core.
Compromised endpoints can leak keys from memory regardless of which cipher is in use, so the surrounding device has to be trusted for the time the tab is open.

Closing the tab and clearing the clipboard once the package has been delivered is the practical finishing step. The JSON container is portable and reproducible, but its security in the wild depends on the channel you choose for the password, the integrity of the device you use, and the willingness of every recipient to keep the package unchanged. For a guide that pairs this workflow with a wider comparison of approaches, see the AES Encryption Online bulk package walkthrough.