Is the AES password sent to a server?

No. Encryption and decryption both run inside your browser through the Web Crypto API. The password is converted to UTF-8 bytes, fed into PBKDF2-SHA-256, and never uploaded, logged, or stored anywhere outside the current page.

Why does encrypting the same text twice produce different packages?

The tool generates a fresh 16-byte salt and a fresh 12-byte IV for every run. That randomness prevents the ciphertext from being deterministic under the same password and is the expected behavior of any correctly used AES-GCM mode.

Can the operator recover a lost password?

No. There is no account, no recovery email, and no server-side key escrow. If you lose the password, the package cannot be decrypted, because the AES key is derived from PBKDF2 using only the salt in the package and the password you provide locally.

Why does decryption fail when the password is wrong?

AES-GCM returns an authentication failure when the 128-bit tag does not verify, and the page reports that failure without exposing partial plaintext. The failure means either the password is wrong or some byte of the package was modified after encryption.

AES Encryption Online Free, No Sign Up: In Your Browser

AES Encryption Online gives you free, sign-up-free AES-256-GCM encryption that runs entirely in your browser using the Web Crypto API. You type plaintext and a password, the page derives a 256-bit AES key with PBKDF2-SHA-256 and 210,000 iterations, then encrypts with a fresh 16-byte random salt, a fresh 12-byte random initialization vector, and a 128-bit authentication tag. The output is a self-contained, versioned JSON package that holds the salt, IV, and authenticated ciphertext as base64url fields, and that package can be copied and shared while the password travels by a separate channel. Nothing is uploaded, no account is created, no email is collected, and there is no server-side key management or escrow — the password never leaves the current page, and the derived key is non-exportable inside the browser. That combination is what makes "free, no sign up" mean something concrete rather than marketing copy: the cryptographic work happens locally, the secret material stays under your control, and the only artifact you hand off is a small JSON blob you can inspect yourself.

Many "free online encryption" pages quietly route your text and password through a server, log IP addresses, attach watermarks, or require an email before they reveal output. AES Encryption Online is built around a different contract: every byte of the cryptographic work happens inside the current browser tab, using the Web Crypto API. The plaintext you type, the derived key, the password, and the decrypted result never leave the page, and the operator does not host a key escrow, a recovery service, or an account database. You can open the tool in a fresh private window, paste a snippet, encrypt it, and close the tab without ever being asked for a name, an email, or a phone number.

That absence is not a cosmetic claim. The 256-bit AES key is derived on the fly with PBKDF2-SHA-256 over 210,000 iterations, and the browser marks the key non-exportable. Because no server ever receives the password, there is no account to compromise, no admin to subpoena, and no backup copy to leak. The "free, no sign up" promise is also why the tool refuses to grow into a managed vault: there is intentionally no way to reset a forgotten password, no way to share access with a teammate, and no way to recover a package if the password is lost. That trade-off is the price of doing cryptography on a page that respects your privacy.

AES-256-GCM Parameters the Tool Uses

The values below are not invented for marketing copy. They are the parameters the Web Crypto API actually requests when the tool runs encryption or decryption, and they are written into the JSON package so a recipient can read them and decide whether they trust the format.

Parameter	Value used by the tool
Cipher	AES-256 in Galois/Counter Mode (GCM)
Key length	256 bits (non-exportable)
Initialization vector	12 bytes, fresh random per encryption
Salt	16 bytes, fresh random per encryption
Authentication tag	128 bits, appended by Web Crypto
Key derivation	PBKDF2-HMAC-SHA-256
PBKDF2 iterations	210,000
Password encoding	UTF-8 bytes
Output encoding	Unpadded base64url (RFC 4648)
Package version	1

GCM is an authenticated mode, so the tag is what lets decryption reject a tampered package. NIST SP 800-38D defines the mode and its IV requirements; the tool follows that guidance by generating a new random IV for every operation rather than asking you to invent one. The 210,000-iteration PBKDF2 cost is the part that slows down password guessing; it cannot rescue a short, reused, or leaked passphrase, but it does force an attacker to spend real CPU per attempt. For a deeper read on these values, the AES-256-GCM parameters cheat sheet walks through each field with example fixtures.

Encrypt or Decrypt a Text Snippet in Your Browser

The workflow has two halves — encryption and decryption — and each one runs from the same page. The steps below are the verified operating sequence and require nothing beyond a modern browser.

Open AES Encryption Online in a current browser. No login, account, extension, or installation is required.
Choose Encrypt, paste or type the text you want to protect into the plaintext field, and enter a unique password of at least 12 UTF-8 bytes. Longer passphrases from a trusted password manager are strongly preferred over anything you can recall by pattern.
Run the encryption. The page generates a fresh 16-byte salt and 12-byte IV, derives the AES key with PBKDF2-SHA-256 over 210,000 iterations, and produces an authenticated ciphertext under AES-256-GCM with a 128-bit tag.
Copy the complete JSON package and preserve it exactly as produced. Send the package to your recipient through one channel — chat, email, file storage — and send the password through a different channel, such as a phone call or a separate messenger. Never paste the password into the same message as the package.
To reverse the operation, switch to Decrypt, paste the unchanged JSON package, type the same password, and run decryption. The page validates the labels, numeric limits, salt and IV lengths, base64url syntax, and minimum ciphertext length before asking Web Crypto to authenticate the package.
If the password is wrong or any byte of the package was modified, Web Crypto returns an authentication failure and the page reports the failure without exposing partial plaintext. Re-check the password and the package integrity before retrying.

Inside the JSON Package You Copy

The artifact you copy is a small JSON document with seven fields: version, alg, kdf, iterations, salt, iv, and ct. version is the integer 1, alg declares "AES-256-GCM", kdf declares "PBKDF2-SHA-256", and iterations is the integer 210000. salt and iv carry the per-run randomness as unpadded base64url, and ct carries the authenticated ciphertext (including the 128-bit GCM tag returned by Web Crypto) in the same encoding. The salt and IV are stored in the open because their job is uniqueness and key derivation, not secrecy. The password is never written into the package, and there is no recovery field, no escrow field, and no hint field.

RFC 4648 is the reference for the base64url alphabet; the tool uses unpadded output, so inserting padded Base64 or changing the URL-safe characters back to standard Base64 will cause validation to fail on the recipient side. Treat the package as a single, opaque blob: do not edit it, do not re-encode it, do not normalize whitespace inside the JSON, and do not reuse an old salt, IV, or ciphertext by hand-editing. The IV must be unique for a given key, and that uniqueness is exactly what the random generation guarantees. Another system can only interoperate if it reproduces the same UTF-8 handling, PBKDF2 parameters, AES-GCM tag placement, base64url encoding, and JSON fields — the surrounding layout is specific to this tool.

Password Rules That Decide Whether It's Strong

The interface rejects passwords shorter than 12 UTF-8 bytes and accepts anything longer. That minimum is a usability floor, not a security guarantee. PBKDF2 with 210,000 iterations is a serious work factor against a single guess, but it cannot compensate for a dictionary word, a reused password, or a phrase that an attacker already knows about you. Treat the password as the only secret and pick it accordingly.

A passphrase generated by a trusted password generator and stored in a password manager is the practical default. If you cannot use a manager, four or five unrelated words chosen at random still beat a clever sentence you can remember, because clever sentences are exactly the patterns attackers try first. The tool does not transmit your password, your derived key, or your plaintext anywhere, but the password is still vulnerable to clipboard managers, browser extensions, screen capture, and shoulder-surfing on shared computers. Clear sensitive fields and close the tab when the surrounding device is not trusted.

When a Local Browser Tool Is the Right Fit

This tool is built for small text snippets, demonstrations, controlled exchanges between two people who can coordinate a password out of band, and compatibility experiments that need a portable, self-contained ciphertext. It is intentionally not a managed vault, not an enterprise key management system, not an encrypted backup service, and not a substitute for application-level cryptographic design reviewed by a security engineer. Larger payloads, long-term storage, and shared organizational secrets deserve a system that handles key rotation, audit trails, and access control, not a password remembered in one person's head.

Scenario	Why the tool fits
One-off secret note to yourself	Encrypt once, store the JSON, recall with a password only you know
Send an API key to a teammate	Package over chat, password by phone, no shared vault required
Verify someone else's package	Decrypt with the password they shared; no re-encryption needed
Test or demonstrate AES-GCM	Self-contained format, base64url fields, no extra dependencies
Replace weaker XOR with a real cipher	Use a real, audited authenticated mode instead of repeating-key XOR

Once the secret you are protecting starts to grow in volume, lifetime, or number of recipients, this page stops being the right tool, and that is by design — the page does not pretend to be more than what it is. Browser extensions, compromised devices, clipboard managers, screen capture, shared computers, and copied package destinations remain outside the cryptographic boundary, and the implementation is checked against NIST AES-GCM vectors and RFC 4648 fixtures rather than certifying the device you happen to be holding.