Encrypt text with a password
- 57 tools
- No watermark
- No daily limit
Type a message, choose a password, and get back a block of text only that password can open. The encryption is done by your browser’s own Web Crypto, using AES-256-GCM with the key stretched by PBKDF2, and neither the message nor the password is sent anywhere. The format is written out below along with a short Python script that reads it, so a message you encrypt today can be opened in ten years whether or not this site still exists.
There is no way to recover this. If the password is forgotten, the message is gone for good. That is not a policy: nobody, including us, holds a copy of the key.
This is how long it takes to turn your password into a key. The wait is the point: somebody guessing passwords pays it once per guess. Normal is 600,000 rounds, which is roughly a second on a laptop and several on a phone.
Encrypting a text file rather than a message
This tool takes text, not files. For a plain text file that is a distinction without a difference, and the round trip is four steps.
- Open the file in any editor and select all of it.
- Paste it into the message box above, choose a password, and run.
- Copy the whole result, including the
LU1at the front, and save it as a new file..txtis fine: the output is ordinary printable characters, so it survives email, chat and copy-paste intact. - Delete the original if the point was to stop somebody reading it. An encrypted copy sitting next to the plaintext protects nothing.
To read it back, paste the encrypted block in and give the same password. The tool notices that the text is one of its own and switches to decrypting on its own.
When this is the wrong approach
| What you have | Use |
|---|---|
| A note, a password to send someone, a config file, a few pages of text | This page. |
| A PDF you need to email | A PDF password, which the recipient's own reader will ask for. No copy-paste step and no instructions to send along with it. |
| A photo, a spreadsheet, a zip, anything not text | 7-Zip or your operating system's own encrypted archive. Base64-ing a binary file through a text box works and is a miserable way to live. |
| A whole folder, or a laptop that might be stolen | Full-disk encryption: FileVault on a Mac, BitLocker on Windows, LUKS on Linux. It is already installed and it protects everything rather than whatever you remembered to encrypt. |
| Something large | Not this. The text goes through a browser text box and the whole thing is held in memory at once, so it is comfortable with a few hundred kilobytes of text and not with a ten megabyte log file. |
Encrypting a list of plain text passwords
If you have found a file of passwords sitting in plain text and you want them not to be, the honest answer is that encrypting the file is the second-best fix and worth knowing the limits of.
Use a password manager instead. Bitwarden, 1Password, KeePassXC and Apple's and Google's built-in ones all solve the actual problem, which is not that the file is readable. It is that a list of passwords has to be decrypted every time anybody needs one entry, and a thing you decrypt five times a day drifts back to living decrypted. A manager keeps the store locked between uses, fills the password without showing it to you, and tells you which ones you have reused. Importing a text file into any of them takes a minute.
When encrypting the file is still the right move: you are archiving credentials you no longer use but cannot delete, handing a set to somebody once, or storing recovery codes you touch twice a year. Those are the cases where a manager is overkill and a single locked block is exactly right. This page is good at that.
If those passwords have been sitting in the open
Encrypting the file now does nothing about the period when it was readable. Assume anything that had access to that file has the passwords, and change the ones that matter. Encryption protects a secret from here onwards; it cannot retract one.
A different meaning of the same phrase
"Encrypt all plain text passwords" is also the answer to a security exam question about a server storing user passwords, and there the answer is do not encrypt them at all. Encryption is reversible, which means the server holds a key that turns every password back into plaintext. Passwords are hashed instead, with a slow function built for the purpose: argon2id, scrypt or bcrypt, each password with its own salt. Nothing on the server can reverse a hash, so a stolen database is not a stolen password list. Verification works by hashing what the user typed and comparing. If you are storing other people's passwords, that is the answer, and this page is not the tool for it.
What the settings do, and which ones matter
Three things are adjustable above. Only one of them changes how hard the result is to break in practice.
| Setting | What it changes | Worth changing? |
|---|---|---|
| AES-256 or AES-128 | The key length. | No. Neither has ever been broken, and 128 bits is beyond brute force by an enormous margin. 256 is the default because it costs nothing. |
| Fast, Normal, Slow | PBKDF2 rounds: how long turning your password into a key takes. Normal is 600,000 rounds, about a second on a laptop. | Only downwards, and only on a slow phone. Somebody guessing passwords pays this cost once per guess, so it is the setting that decides how many guesses per second they get. |
| Your password | Everything. | This is the whole of it. See below. |
The rounds and the key length are the parts people fiddle with and they are not where the strength lives. A four-word passphrase moves the difficulty of guessing by more than every other option on this page combined, because an attacker does not attack AES. They guess passwords, and 600,000 rounds only multiplies the cost of each guess. Multiplying a small number is still small.
Roughly: a common word with digits after it falls in seconds even at the slow setting. Four random words falls to nothing anyone will build. If you need one, the password generator on this site makes both kinds and shows the arithmetic.
What it does not hide
The encrypted block announces its own format: it starts with LU1
and its length is close to the length of your message. Somebody who intercepts
it knows a message was sent, roughly how long it is, and what made it. That is
true of all encryption of this shape and it is why the format is published
rather than obscured. Hiding the fact that you sent something is a different
problem with different tools.
Frequently asked questions
Is my message uploaded?
No. The encryption happens in this tab using your browser’s built-in Web Crypto. The site’s security policy sets connect-src ‘none’, so the browser blocks network requests from these pages, meaning neither the message nor the password could be sent even if the code tried.
What exactly is it doing?
Your password is stretched into a key with PBKDF2-HMAC-SHA256 and a random 16-byte salt, then the message is encrypted with AES-GCM and a random 12-byte nonce. AES-GCM is authenticated, which means a message altered in transit fails to decrypt rather than quietly producing different text. None of that is written here: every step is a call to the browser’s own implementation.
Why is there no choice of algorithm?
Because the choice would be a way to get it wrong. Web Crypto also offers AES-CBC and AES-CTR, and neither authenticates on its own: somebody could change the message in transit and decryption would hand back plausible rubbish with no complaint. Key length and work factor are adjustable because every option there is safe.
What if I forget the password?
The message is gone. There is no reset link and no back door, because there is nothing to reset: the key exists only for the moment it is being used, and no copy of it is stored anywhere, here or elsewhere. Write the password down somewhere you trust before you rely on this.
What if this site disappears?
Your messages still open. The container format is published in full below and holds everything a reader needs at fixed byte positions, so the Python script on this page will decrypt anything this tool produced. That is the whole reason it is written down.
Should I use this for something that really matters?
For sending a password or a document to a colleague, yes: it is standard cryptography, done by your browser, with the parameters stated. For protecting something against a determined attacker with time and money, understand what it does and does not do. It protects the message. It does not hide that you sent one, and it is only ever as strong as the password you chose.