Logo

Encrypt Text Online

Lock a message behind a password using AES-256. It happens in this tab, and the password never leaves it.

There is no recovery. Forget this password and the text is gone for good — not held somewhere pending a support request. Any tool offering to recover it has kept a second, weaker key. Save the password somewhere before you close this tab.

What runs here: AES-256-GCM through the browser's own Web Crypto, with the key stretched from your password by PBKDF2-SHA256 at 600,000 iterations — the figure OWASP currently recommends.

Open the network tab and encrypt something. You will see no request, because there is nothing to send. That is worth checking on any tool that claims it, including this one.

You have something to send that should not sit in plain text. Email keeps copies on servers you do not control, chat apps sync to a laptop somebody else can open, and a screenshot lives forever. Encrypt text online first and the message becomes a string that means nothing without your password.

How to encrypt a message with a password in three steps

Type the message, pick a password, press the button. The whole thing takes under a minute, and most of that minute is you deciding on the password.

Length beats cleverness. A four-word phrase you will actually remember holds up far better than eight characters with a symbol jammed in the middle. If you want the machine to choose, our generate a strong password tool makes one and our strength read-out will tell you honestly what it thinks of it.

The awkward part is what happens next. You now have two things to move — the message and the password — and sending them together defeats the exercise completely. We go through the sensible routes in how to send a password securely, including the ones people reach for that do not work.

What client-side encryption actually protects you from

Everything here runs in your browser. The message is never uploaded, so there is no server log, no database row, and nothing for us to hand over if somebody asks.

That claim is checkable, which matters more than the claim itself. Open your browser's network tab, encrypt something, and watch for a request. There is not one. Any tool that says the same thing and does not survive that test is telling you something else.

Now the part most pages leave out. Client-side means the code runs on your machine; it does not mean the code is above suspicion, because we still serve the JavaScript. A page compromised at the source could send your text somewhere on the next visit and pass the same network test today. That is true of every browser crypto tool, ours included, and we work through what it means in whether online encryption tools are safe.

Why we took password recovery out

An earlier version of this page offered security questions. Answer three, and it would give you your password back if you forgot it. It was the most popular thing on the page and it should never have shipped.

Here is what it was doing. Your password was encrypted with a key built from your three answers and attached to the output, along with the questions in plain text and a hash of each answer. Those hashes let anyone holding the file test each answer separately, so three easy guesses could be worked out one at a time rather than all at once.

The result was AES-256 protected by a mother's maiden name. We removed the feature rather than patching it, because the flaw was the idea. If you have an old file with that block in it, the decrypt page will read it and tell you to re-encrypt — and what to do when the encryption password is lost explains why the honest answer is uncomfortable.

How to encrypt text without software on your machine

Nothing to install, nothing to update, nothing left behind on a shared computer. That is the real appeal of doing this in a tab, and it is why people search for it from work laptops they cannot install anything on.

The comparison with desktop tools is not all in our favour, though. GnuPG and VeraCrypt do things this cannot: signing, key exchange between people who have never met, whole encrypted volumes. If you need to prove who wrote a message rather than just hide it, you need a signature, and that means keys rather than passwords.

For a short message going to one person who can be told a password, a browser is enough. Once the page has loaded you can even disconnect from the network and it keeps working, which is a reasonable way to satisfy yourself about the earlier claim.

Choosing a text encryption tool you can check yourself

Most pages in this category say the same four things: AES-256, military-grade, bank level, nothing leaves your browser. Three of those phrases are marketing and one is testable.

Two questions sort the field quickly. Does it work with the network disconnected? And does it offer to recover your password? A yes to the second means a second key exists somewhere, no matter how the page describes it.

We would add a third, less obvious one: what does it do when decryption fails? A tool that says only "failed" is hiding the fact that it cannot tell a wrong password from a damaged file. Ours separates the cases it genuinely knows from the one case it cannot, which is the whole design of the decrypt text page.

What the output hides, and what it does not

The content is unreadable. Several other things are not, and pretending otherwise would be the same overclaiming we are trying to get away from.

  • The length. Ciphertext is roughly the size of the text that went in. A one-line message looks like a one-line message. Pad it with filler if the length itself gives something away.
  • That encryption happened. The output starts with a marker that says which tool made it. We keep it because it is what lets us tell you that you pasted the wrong string, and hiding it would only trade a real feature for a false sense of stealth.
  • The timing. When you sent it, to whom, how often. That is metadata, it lives outside the message, and no encryption tool touches it.
  • Your device. Anything that reads the screen or the keyboard sees the text before we do.

When encrypting text is the wrong answer

Sometimes there is a better tool, and sending you to it costs us nothing.

For a file rather than a message, encrypt the file itself instead of pasting its contents — our encrypt a file online page handles any format and keeps the original name. For a plain .txt sitting on your own disk, there are operating-system routes worth knowing first, which we cover in how to password protect a text file along with the trap that catches people copying to a USB stick.

And if what you actually want is a puzzle rather than protection, ROT13 and Caesar shifts are a different job entirely. They are reversible by anyone in seconds, they are meant to be, and they live on our classical ciphers like ROT13 and Caesar page.

Encrypt text online, then look after the password

The tool is the easy half. AES-256-GCM with the key stretched by PBKDF2 does its job, and the mode we chose checks the message has not been altered as well as hiding it — the reasoning is in why GCM beats CBC.

The hard half is everything around it. Store the password in a manager rather than a notes app, move it through a different channel from the message, and remember that the person receiving it can be careless on your behalf.

We would rather you left this page knowing what it does not do than believing it does more. That is a strange thing for a tool page to say. It is also the only version of this we are willing to publish.

Frequently Asked Questions

Why is there no option to recover a forgotten password?

+
Because every recovery path is a second key, and a second key is only as strong as its weakest input. An earlier version of this tool offered security questions, and it worked by encrypting your password under three answers and attaching it to the output. That turned AES-256 into a guessing game about a first pet, so we removed it rather than improved it.

Does the encrypted output reveal how long my message was?

+
Yes, roughly, and no tool of this kind hides it. Ciphertext is about the same length as the text that went in, so a one-word message and a thousand-word one are obviously different sizes. If length itself is sensitive, pad the message with filler before encrypting.

I encrypted the same sentence twice and got two different results. Is that a bug?

+
That is the tool working correctly. A fresh random salt and a fresh random starting value go into every run, so identical input never produces identical output. It matters more than it looks: without it, anyone watching could tell that you had sent the same message twice.

Someone altered one character of my encrypted text. Do I get most of the message back?

+
No, you get nothing, and that is deliberate. The mode we use checks the whole block before releasing any of it, so a single changed byte fails the check outright. Partial recovery would mean an attacker could edit your message and have you read the result.

Are 600,000 iterations overkill on an older phone?

+
Less than people expect. The page measures the real figure on your own device and prints it under the tool, and on the desktop we tested it came out at 67 milliseconds. The wait is the point: it costs an attacker the same on every guess. It is also why your password still matters most, because a machine built for cracking runs thousands of those guesses in parallel.

My encrypted text stopped working after I sent it through a chat app. Why?

+
Messaging apps and email clients rewrite text more than people expect. They insert line breaks in long strings, convert straight quotes to curly ones, and sometimes autocapitalise. Any of those changes the data, so send it as a file attachment or a code block when the string is long.

Will something I encrypt today still open in a few years?

+
It should, because the format carries its own settings. The iteration count is written into every output rather than assumed by the reader, so raising it later cannot strand anything already encrypted. We also still read files from our older vault format for exactly this reason.

Can my employer see what I type here on a work laptop?

+
Possibly, and this is the limit people miss. Browser encryption protects the message in transit and at rest; it does nothing about the device you typed it on. Managed laptops often run monitoring agents that capture keystrokes or screenshots before any encryption happens.

Do browser extensions weaken this?

+
They can, and we would rather say so. An extension with permission to read page content can see your text and your password as you type them, the same way it can on any website. If the message genuinely matters, use a private window with extensions disabled.

Is it sensible to encrypt a password and send that?

+
It moves the problem rather than solving it, because now the recipient needs the encryption password instead. It works when you already share something they know and an interceptor does not. Otherwise a password manager's sharing feature is the better route.

Related Tools You Might Like

Advertisement