What 'your data never leaves your machine' really means

Every privacy tool sounds the same. They are all private. They are all secure. They all care about your data. The words are free to use, so everyone uses them, and that is the problem. By the time you have read three product pages, the language has stopped meaning anything. You cannot tell the careful tools from the careless ones, because they describe themselves with the same vocabulary.

So drop the words and look at the path your data actually takes. The path does not lie. It either includes other people or it does not.

Encrypt is not the same as never see

Start with the most common privacy claim: "we encrypt your data." It sounds final, but it answers a narrower question than you think. Encryption protects your data in transit and at rest, which means while it travels across the network and while it sits in storage. That is real protection against an outsider who intercepts the traffic or breaks into the database.

What encryption does not tell you is who holds the keys. If the service can read your data to process it, then somewhere in the pipeline that data is decrypted, in plain readable form, on a machine the service controls. Encryption is the locked armored truck. It says nothing about who is allowed to open the back doors once the truck arrives.

"We encrypt your data" is a statement about how your data is protected from third parties. It is not a statement that the service itself cannot see your data. Those are different promises, and the gap between them is exactly where confidential text gets read, logged, or used in ways you never agreed to.

"Your data never leaves your machine" is the stronger claim because it removes the question entirely. If nothing crosses the network, there is no truck, no keys, and no one else in the path. There is no one to trust with the back doors, because there are no back doors.

What local and offline actually mean

Two plain words sit underneath that stronger claim, and both deserve clear definitions.

Local means the work happens on your own device. When you run a local tool, your text is read, processed, and handled by software running on your computer. The result appears on the same machine. Your data was never sent anywhere to get the job done.

Offline means the tool does not need a network connection to function. You could pull the cable, turn off the wifi, and the tool would still work, because it was never reaching out to a server in the first place. Offline is the proof that local is real. A tool that genuinely processes everything on your device has no reason to call home, so it keeps working when the network is gone.

Put together, local and offline describe a tool with no one else in the path. Not because the company promises good behaviour, but because the architecture leaves no room for anyone else to participate.

Proof beats promise

Here is the shift that protects you: stop asking whether a tool is private and start asking how you would know. A claim you can check is worth more than a claim you have to believe, because belief depends on the vendor staying honest forever, and checking does not.

This is where most marketing falls quiet, because most tools cannot be checked. Their processing happens on servers you cannot see, running code you cannot read, governed by policies that can change next quarter. You are asked to trust the chain. A tool that runs on your own machine, with code open to inspection, asks for nothing. You can confirm the behaviour yourself.

That is the standard worth holding any privacy tool to.

How to verify any privacy claim

You do not need to be an engineer to test most of these. Work down the list and let the answers, not the adjectives, decide your trust.

• Pull the network. Turn off wifi or unplug the cable and try the tool. If it still does the job, the work is genuinely happening on your device. If it stops, your data was going somewhere.
• Watch the traffic. Network monitoring tools, including ones built into your operating system, can show you whether an app makes outbound connections while it runs. No calls means no data leaving.
• Read the code, or check that someone could. Open source means the claim is open to inspection by anyone, not just taken on faith. Closed code asks you to trust a description of behaviour you cannot confirm.
• Ask where the processing happens, on your device or on their server. If the raw text touches their server, the "never see" claim is gone, no matter how strong the encryption around it.
• Ask what is logged or retained, by whom, and for how long. A clear, specific answer is a good sign. A vague one is the answer.

Where Velum stands

This is the standard we hold ourselves to. Velum runs locally and offline, with no network calls while it works. There is no Velum server that sees your raw text, because your text never reaches us. Pull the cable and Velum keeps working, which is the first test in this list and the one we would run first ourselves. The engine is source-available via npm under PolyForm Noncommercial, so the claim is also something you can read rather than something we ask you to believe.

We would rather show you the path than describe it. See how Velum handles your data on your own machine, and read through the use cases to find where it fits your work.