No upload, 100% local, no account

How-to

How to encrypt sensitive content before sending it

Emailing a password list, an API key, or a short confidential note as plain text means anyone who intercepts the message, or anyone with access to a mailbox down the line, can read it directly. This guide generates a strong passphrase and encrypts the content locally with AES-256-GCM, so what actually travels through your email or chat app is unreadable ciphertext rather than a file sitting on someone else's server waiting to be scanned or copied.

Step by step

  1. Open the Password Generator, set the length to at least 20 characters with every character class enabled, and generate a passphrase. Copy it somewhere temporary; you will share it with your recipient through a different channel than the one carrying the encrypted content, for example a phone call or a messaging app you already use for something else.
  2. Open the AES Encrypt tool, paste the text you want to protect (the content of a password list, an API key, a config file, or any short note) into the input field, paste the passphrase from step 1, and click Encrypt. The tool derives a key from your passphrase with PBKDF2 and encrypts with AES-256-GCM, both running in your browser, and returns a block of ciphertext text.
  3. Paste that ciphertext block directly into the body of your email or chat message. Nothing needs to be attached: the sensitive content now travels as unreadable text. Separately, tell your recipient the passphrase through the other channel, and ask them to paste the ciphertext and the passphrase into the same tool and click Decrypt to recover the original content.

How this compares to uploading a file to an online encryption service

Many services that offer to encrypt a file work by receiving your file on their server, encrypting it there, and letting you download the result: the plaintext content passes through a system you do not control, if only for the seconds it takes to process. The AES Encrypt and Password Generator tools here run entirely in your browser using the Web Crypto API: encryption uses AES-256 in GCM mode, and the passphrase is stretched into a key with PBKDF2-SHA-256 at 310,000 iterations, with a fresh random salt and initialization vector every time. None of the plaintext, the passphrase, or the ciphertext is sent to any server during the process.

Sharing the passphrase without undoing the protection

Encryption only protects a message if the passphrase travels separately from the ciphertext. Sending both in the same email thread, or right after each other in the same chat, gives anyone who reads that thread everything they need. Read the passphrase aloud on a call, send it through a messaging app unrelated to the one carrying the encrypted text, or hand it over in person for anything genuinely sensitive. Store it afterward in a password manager rather than leaving it in the conversation.

What this method does not cover

The AES Encrypt tool accepts text, up to about 1 MB, rather than an arbitrary binary file dropped in directly. It works well for a password export, a config file, or any content you can open and copy as text. For a genuine binary attachment such as a photo or a small document, the Base64 tool can turn the file into a block of text first; you would then encrypt that text the same way, after manually removing the data-URI prefix the encoder adds in front of it. The size ceiling drops further once Base64 inflates the data by about a third, so this only suits small files. For protecting a PDF specifically, adding a real password to the file with the PDF Password tool is a better fit: it encrypts the document itself, with no comparable text-size limit.

The tools used in this guide

Frequently asked questions

Is the passphrase or the text I encrypt ever sent to a server?

No. The Password Generator and the AES Encrypt tool run entirely in your browser using crypto.getRandomValues and the Web Crypto API's crypto.subtle. Nothing you type is transmitted anywhere at any point; you can confirm this yourself by opening your browser's developer tools, watching the Network panel, and running through the whole process.

What happens if the passphrase is lost?

The ciphertext cannot be recovered without it. There is no recovery option and no backdoor: PBKDF2 at 310,000 iterations makes brute-forcing a genuinely random 20-character passphrase impractical. Keep the passphrase in a password manager rather than only in the conversation where you shared it, so losing that one message does not also cost you the content.