How to Encrypt Text with AES-256 (Fully Offline)

Why Browser-Based Encryption Is Different

Most encryption tools you find online send your message to a server, encrypt it there, and hand back the result. That means the provider has seen your plaintext, and you must trust their logging, their infrastructure, and their staff not to misuse it. AES Encrypt & Decrypt works differently: it uses the Web Crypto API built into your browser, so the key is derived and applied on your device. Your plaintext and passphrase never leave your machine at all — there is no server to intercept, no upload to audit, and nothing to trust beyond your own browser. For a note you do not want sitting in a cloud provider's logs, or a secret you plan to send through an ordinary messaging app, this local-only approach is meaningfully more private than a hosted service. It also removes the timing and availability concerns of a third party: the tool works whether or not any server is reachable, because the work happens entirely in the page. There is no account to create, no quota to hit, and no history of your activity kept anywhere. Privacy is not a feature bolted onto this tool; it is the architecture. When the underlying browser is secure, the only weaknesses that remain are your passphrase and your own handling of it.

How AES-256-GCM Encryption Works

At the heart of the tool is AES-256-GCM, a modern authenticated encryption cipher. AES-256 is a symmetric block cipher — the same 256-bit key encrypts and decrypts, which is why the recipient needs the passphrase you used. GCM adds an authentication tag, so a ciphertext that has been tampered with, even by a single character, fails decryption instead of producing corrupted garbage. With current hardware, brute-forcing a full 256-bit key is computationally infeasible, so the practical strength of your encryption is determined by your passphrase. Two extra pieces make the scheme workable in practice. Every encryption generates a random 16-byte salt, and the key is derived from your passphrase using PBKDF2 with 150,000 iterations of SHA-256 — slow enough that guessing passwords is expensive, fast enough that encrypting feels instant. A random 12-byte IV (initialization vector) is also generated each time, so encrypting the same message twice with the same passphrase produces completely different ciphertext. The salt, IV, and ciphertext are stored together in the output in Base64. The result looks like three Base64 chunks separated by colons, and that self-contained bundle is what lets you decrypt on any device with the same passphrase. This packaging is why you never have to manage salt or IV yourself.

When to Use Text Encryption

Reach for this tool whenever you need to move a small secret through a channel you do not fully trust. Typical cases include sending a password or an API key over email or a messaging app so it is not sitting in a chat log in plaintext; leaving an encrypted note on a shared drive, a ticketing system, or a bug report where other people can read files; and storing backup codes, recovery keys, or answers to security questions in a form that is useless to anyone who finds the file. The GCM authentication tag also lets you verify that a message has not been altered in transit — a modified ciphertext simply fails to decrypt, which tells you something was wrong rather than silently feeding you bad data. It is equally useful for secrets that must survive across devices: encrypt once on your laptop, decrypt on your phone later, without any cloud account in between. Writers use it for drafts of sensitive articles, developers use it for one-off secrets that do not justify a full secret-management system. What it is not for matters too. It is not a replacement for file encryption on large documents, and it does not protect data at rest on your own unlocked machine — disk encryption and a locked session handle that. For short secrets moving through untrusted channels, this is the right tool.

How to Encrypt Text with AES Encrypt & Decrypt

Encrypting takes a few seconds and the output is self-contained: a single string you can copy, download, or send, which contains everything needed to decrypt it. Keep the passphrase separate and you can pass the secret safely through any channel.

1. 1Open the AES Encrypt & Decrypt tool and confirm Encrypt mode is selected
2. 2Type or paste your message into the Message box
3. 3Enter a strong passphrase in the Password field
4. 4Click Encrypt and wait for the salt:iv:ciphertext output
5. 5Copy the ciphertext or download it as a .txt file
6. 6Send the passphrase to the recipient through a separate channel

How to Decrypt and Share Safely

To open the message later, or on another device, switch the tool to Decrypt mode, paste the complete salt:iv:ciphertext string into the text box, and enter the same passphrase. Because the output already contains the salt and IV, the recipient needs only that string plus the passphrase. If they enter a wrong password, or the data has been altered in any way, the tool reports an error instead of printing garbage — that is the GCM authentication check doing its job. The safe-sharing pattern is to send the ciphertext over one channel and the passphrase over a different one: the ciphertext by email, the passphrase by phone or in person. That way a compromise of a single channel does not hand over the secret. Never paste the passphrase into the same message as the ciphertext, and avoid typing it anywhere that auto-syncs to a cloud clipboard. If you are the only person who needs the secret, the same rule applies to yourself — store the passphrase in your password manager and the ciphertext in a file or note, not both in the same place. Before you share, decrypt once yourself with only the exact string you are about to send, to catch any copy-and-paste mistake on the recipient's behalf.

Choosing a Passphrase That Holds Up

The encryption is only as strong as your passphrase, because anyone who guesses it can derive the same key. PBKDF2 with 150,000 iterations slows brute force down dramatically — every guess costs 150,000 hash rounds — but a short, dictionary-based passphrase will still fall to a determined attacker with enough computing power. Aim for at least 16 characters that mix upper and lower case, digits, and symbols, and make it unique to this secret instead of reusing a password you have used elsewhere. A passphrase made of four or five unrelated words is long, memorable, and far stronger than a single mangled word like Password1. Avoid the obvious: names, birthdays, pet names, and anything that appears in your social profiles or in documents about you. If the secret is important, use the random password generator in your password manager to create the passphrase and store it there, rather than trusting your memory. Remember that there is no password reset. If you lose the passphrase, the ciphertext is permanently unreadable — by you and by everyone else. That is the defining property of good encryption, and it means you should treat the passphrase with the same care as the message itself.

Common Mistakes and Limits to Know

Most encryption failures are operational, not mathematical. Losing the passphrase makes the data unrecoverable by design, so store it somewhere you trust before you encrypt anything important. Editing the ciphertext — even deleting one Base64 character — guarantees decryption fails, because both the salt and the GCM authentication tag are baked into that string; always copy the entire output, never a truncated fragment. Sending the passphrase through the same channel as the ciphertext defeats the whole point of encrypting. And do not mistake this for device protection: the tool keeps text private in transit and at rest in a file, but anyone who unlocks your computer while you are logged in can read whatever is on screen. The output format is also specific to this tool's scheme, so it decrypts here or in another AES-GCM library that accepts the same salt, IV, and ciphertext layout. It is not a PGP-style format, and not every encryption tool will understand it. If you need an interoperable, standards-heavy format with recipient keys and signatures, use PGP instead. For the common case — you and one trusted person sharing a secret — this tool's format is simple and works, provided both of you use it correctly.

A Worked Example, Step by Step

A concrete example shows how the pieces fit together. Suppose you need to send a Wi-Fi password to a colleague over Slack, which keeps a searchable history. Open AES Encrypt & Decrypt in Encrypt mode, type home-wifi-2026 in the Message box, and set a passphrase like Trout-Basket-79-Mango. Click Encrypt, and the tool returns a single line resembling base64salt:base64iv:base64ciphertext. That string, even with the passphrase known, is useless to anyone skimming the Slack archive, because the archive holds only the ciphertext. Send the passphrase by a separate channel — a phone call or an SMS — and the colleague pastes the full string into Decrypt mode, enters the passphrase, and reads the original text. Now vary one detail to see the crypto working. Encrypt the same message again with the same passphrase, and the output is completely different, because the salt and IV are regenerated every time; that is what prevents an attacker from detecting that two encrypted strings contain the same message. Change a single character in the ciphertext before decrypting, and the tool reports an error instead of outputting garbage, because the GCM tag no longer verifies. Run the whole flow once on a throwaway message before you trust it with a real secret, so you are certain of every click.

Frequently Asked Questions

Will decryption ever work with a wrong passphrase? No — the GCM authentication check fails, and the tool reports an error. What if the passphrase is right but I mistyped the ciphertext? Same result, an error, because the tag depends on the exact ciphertext bytes. Can I use this to protect files on my own computer? It encrypts text, not files; for data at rest, use your operating system's disk encryption and keep your session locked. Is the encryption genuinely secure? AES-256-GCM is a widely deployed, respected cipher, and the key derivation uses PBKDF2 with 150,000 iterations; the practical weak point is always the passphrase, not the cipher. Does the browser store anything? No — the plaintext, the passphrase, and the derived key exist only in the page's memory and vanish when you close or reload the tab. Can someone intercept the encryption? The whole computation runs in your own browser session, so nothing is transmitted to intercept. What happens if I lose the passphrase? The data is unrecoverable; there is no backdoor by design. How does this compare to PGP? PGP adds public-key identities and signatures and is the standard for interoperability, but it is heavier to use; this tool trades that for simplicity when both parties can use it. Keeping these answers in mind removes most of the uncertainty people feel on their first use.