AES-256 Encrypt / Decrypt Online - Free, In-Browser

AES-256 is the Advanced Encryption Standard with a 256-bit key, the largest of three standard AES key sizes. It is approved by NIST and NSA Suite B for protecting classified information up to TOP SECRET. A 256-bit key means a brute-force search covers 2^256 possibilities, astronomically beyond any current or foreseeable computing effort. The practical reason to pick 256 over 128 is a larger safety margin against future cryptanalysis and against Grover's algorithm, which leaves roughly 128 bits of effective post-quantum security.

Yes, provided the tool runs entirely in your browser and never sends your plaintext to a server. This page uses the browser's native Web Crypto API (the same implementation used for TLS) and performs salt generation, PBKDF2 key derivation, AES encryption, and Base64 encoding locally. Nothing is uploaded, logged, or written to persistent storage. You can confirm this in DevTools Network and even disconnect from the internet after the page loads. The remaining risk is your own device - malware can read plaintext before encryption no matter what tool you use.

They differ in key length, round count, and safety margin. AES-128 uses a 128-bit key and 10 rounds; AES-192 uses 192 bits and 12 rounds; AES-256 uses 256 bits and 14 rounds. All three are secure against every known classical attack. AES-128 is about 40 percent faster per byte than AES-256 on hardware without AES-NI, but the gap is negligible on modern CPUs. Pick AES-256 for long-term archives, AES-128 when constrained by an older system, AES-192 only when a compliance profile mandates it.

Use GCM unless you have a specific reason to pick something else. AES-GCM is authenticated encryption: it provides both confidentiality and integrity in a single pass, so a tampered ciphertext is detected on decrypt instead of silently returning garbage. AES-CBC and AES-CTR only provide confidentiality, so an attacker who modifies the ciphertext can corrupt plaintext without being caught, and CBC historically suffers from padding-oracle attacks. Pick CBC or CTR only to interoperate with a system that mandates them, and combine with a separate HMAC when integrity matters.

No. Everything runs inside your browser through the Web Crypto API. Plaintext, password, salt, IV, and ciphertext are created and consumed locally, never serialised over the network or written to persistent storage. You can disconnect from the internet right after the page loads and the tool keeps functioning. The only bytes that travel over the network are the static page assets themselves, cached by Cloudflare.

Every Encrypt click generates a fresh 16-byte random salt and a fresh IV (12 bytes for GCM, 16 for CBC and CTR). Both are stored inside the Base64 output so decrypt can recover them. Randomising salt and IV means identical plaintexts never produce identical ciphertexts, so an attacker learns nothing by comparing outputs. Reusing an IV with the same key is catastrophic in every AES mode, which is why the tool regenerates it on every call.

The ciphertext is mathematically unrecoverable without the correct password. AES combined with PBKDF2 at 100,000 iterations has no backdoor, no master key, no password-reset. Brute forcing a strong password (a long random passphrase or a 16-character password-manager output) is infeasible within any realistic timescale. Store the password in a password manager or write it down somewhere physically secure. Lose it and the encrypted data is permanently inaccessible - that is the point.

Only if the other tool implements the same format. This page prepends a three-byte header (<code>version | mode | keyBits</code>) before the <code>salt | iv | ciphertext</code> layout and uses PBKDF2-HMAC-SHA-256 at 100,000 iterations with a 16-byte salt. If integrating with custom code, replicate the header parsing, use <code>crypto.subtle.importKey</code> + <code>deriveKey</code> with matching parameters, and run the corresponding AES mode. Cross-tool compatibility is easiest with the legacy layout (AES-256-GCM, no header) older versions of this tool emitted.

Yes. The tool encodes text as UTF-8 with <code>TextEncoder</code> before encryption and decodes the same way after decryption, so Chinese, Arabic, Cyrillic, and emoji all survive a full round trip. Raw binary data (images, PDFs) is not supported through this text-only interface; for that, Base64-encode the binary first with the <a href="/tools/base64-encode-decode/">Base64 tool</a> and encrypt the resulting text. Decrypt, then Base64-decode to recover the original bytes.

There is no protocol cap below 2^39 bytes per AES-GCM key, but browser memory is the practical limit. Inputs up to roughly a megabyte encrypt in well under a second. Tens of megabytes briefly freeze the tab during PBKDF2, and anything near a gigabyte risks crashing the page. For large files, prefer a streaming desktop tool such as <code>openssl enc</code>, <code>age</code>, or <code>gpg --symmetric</code>.