You paste something private into a website that promises it never leaves your browser. You have no way to check, and the page that means it looks identical to the one that does not. Free encryption sites are trivial to build and the honest ones look exactly like the rest.
There is a test that settles most of it, and it takes about a minute. We will go through it, then apply it to our own pages.
Does client-side encryption really work, or is it a slogan?
It works, and the phrase is used by tools that do nothing of the kind.
Client-side means the encryption runs in JavaScript on your machine, so the plain text never travels. The browser has a proper cryptography library built in — Web Crypto — and a tool using it is doing genuine AES with no upload involved.
The abuse is that nothing stops a page saying "client-side" while quietly posting your input to a server. Both versions render the same buttons. The phrase is a claim, not a property.
That is the whole problem in one sentence: the marketing is free and the behaviour is invisible. So stop reading the claim and test the behaviour.
How to tell if a browser tool uploads your data in about a minute
Open the developer tools with F12, switch to the Network tab, and clear it. Then encrypt something and watch.
You are looking for a request that fires at the moment you press the button. Page assets loading beforehand are normal — scripts, fonts, an analytics ping. A request that carries your input, at the moment you submit it, is the thing that matters. Click it and read what was sent.
The stronger version of the test takes ten more seconds. Load the page, turn off your wifi, then encrypt. A genuinely local tool carries on working. Anything that needs a server fails immediately, and it cannot fake its way past that.
Try it here. Load our encrypt text online free page, disconnect, and encrypt something — it works, because there is nothing to send. We would rather you checked than took our word for it.
The risks of free encryption websites nobody advertises
Assume the tool is honest today. Four things can still go wrong, and they are worth naming.
- The code can change. You verified Tuesday's version. Wednesday's arrives from the same URL with no announcement, and there is no signature to check.
- Third-party scripts. An analytics or ad script loaded into the same page has the same access to it. The tool's own author may not have read that code either.
- Your extensions. Anything with permission to read data on all sites can see your text and your password as you type.
- The clipboard. Copying the plaintext puts it somewhere other applications can read, and some clipboard managers keep history for weeks.
None of that is a reason to avoid browser tools. It is a reason to keep the sensitive things short-lived and to use a clean window when it genuinely matters.
The limit that applies to us as well
Here is the part we cannot argue our way out of, so we will state it plainly instead.
We serve the JavaScript. If our site were compromised at the source, a modified page could send your text somewhere on your next visit, and the network test you ran last week would tell you nothing about it. That is true of every browser encryption tool ever built, including this one.
What reduces it: no third-party scripts on the tool pages, no shareable links, nothing stored server-side, and standard Web Crypto primitives rather than anything homegrown. What does not eliminate it: any of those, or a reassuring paragraph.
We have had our own version of this lesson. An earlier release of our vault tool offered password recovery through security questions, which quietly reduced AES-256 to three guessable answers. We shipped it, we found it, we removed it — and there is no recovery covers why that idea cannot be repaired.
What separates a careful tool from a careless one
Five questions sort the field faster than any badge.
Does it work offline? The single most useful test, and the hardest to fake.
Does it offer password recovery? If yes, a second and weaker key exists somewhere. There is no version of recovery that does not mean that.
Does it state its key-stretching settings? A tool quoting an iteration count has thought about offline guessing. One quoting only "AES-256" may be feeding your password straight in as a key.
What does it say when decryption fails? A single red "failed" hides the fact that most failures are structural. A tool that distinguishes a truncated paste from a wrong password has done real work.
Does it mint links? Links need a server. That can be done well, and it is a different trust model from one that stores nothing — which is also the honest reason we do not build one, as covered in sharing the password afterwards.
Where browser tools genuinely beat the alternatives
The realistic comparison is not against a perfect audited system. It is against what people actually do when security is inconvenient, which is send the thing in plain text.
A browser tool installs nothing, needs no admin rights, and leaves nothing behind on a shared machine. On a locked-down work laptop it is often the only option that exists, and file encryption in the browser covers the same ground for documents rather than messages.
The same reasoning runs through the rest of our tools. Reading a photo's hidden fields with read a photo's metadata locally keeps the photo on your machine for exactly the same reason: sending a file somewhere to learn one fact about it is a bad trade.
So are they safe?
The good ones are, for the things browser tools are good at: short messages, single files, one-off jobs where installing software is not realistic.
They are not the right answer for a key you must protect for years, for an organisation with a compliance obligation, or for a threat model involving anyone with real resources. Those need audited software, managed keys and someone accountable.
Run the offline test on any tool you are considering. If it fails, close the tab. If it passes, you have learned more in one minute than any amount of homepage copy could tell you.