You can be told a tool does not store your data. You cannot verify it from a privacy policy. But there is one thing you can check yourself, in about two minutes, without being technical: whether the tool sends what you type anywhere at all.
This will not tell you everything. It will not tell you what a company does with data after it receives it, whether that data is used for training, or how long it is kept. Those questions require asking the vendor directly. What this check tells you is narrower and still valuable: when you type into a tool, does your input leave your browser, and if it does, where does it go. For a tool that claims to keep your data local, that is the claim you can confirm or catch.
Here is how.
What you are looking at
Every time a web page sends or receives information, that exchange is called a network request. Your browser has a built-in panel that shows every one of these requests in real time. It is meant for developers, but you do not need to understand the code to use it. You are only watching for one thing: does typing into the tool create a new request, and if so, where is it going.
If a tool processes your input on its own server, you will see a request fire when you submit. If a tool runs entirely on your device, you will see nothing when you type. That difference is the whole test.
Step one: open the network panel
In Chrome or Edge, right-click anywhere on the page and choose Inspect. A panel opens. Along the top of that panel, click the tab labeled Network.
In Safari, first enable the developer tools if you have not already. Go to Safari, then Settings, then Advanced, and check the box for Show features for web developers. Then right-click the page, choose Inspect Element, and click the Network tab.
In Firefox, right-click, choose Inspect, then click the Network tab.
You now see a table. It may already be filling with the requests the page made when it loaded. That is normal. Those are the page fetching its own images, fonts, and code.
Step two: clear the list
You want a clean slate so you can see only what happens when you type. Look for a clear button in the network panel toolbar. It is usually a circle with a line through it, or a small trash can icon. Click it. The list empties.
Step three: use the tool and watch
Now type into the tool. Enter a prompt, fill in a field, do whatever the tool is for. Then submit or save, whatever action the tool takes with your input. Watch the list the entire time.
Two outcomes.
If the list stays empty, the tool sent nothing. Your input did not leave your browser. There was no server call, because there was nothing to call. For a tool claiming to keep your data local, this is confirmation.
If a new request appears, the tool sent something. Click that request. Look at the domain it went to, shown in the list. That tells you where your input was sent. This does not automatically mean the tool is doing something wrong. Most useful tools legitimately send data to a server to function. It means the tool's claim to be local is false, and you now know your input is leaving your device, which is the thing you needed to know before putting anything sensitive into it.
One thing that will confuse you, and how to handle it
You may see requests appear that have nothing to do with the tool. Browser extensions are the usual cause. A writing assistant like Grammarly, for example, watches text fields on every site and will fire its own requests when you type, regardless of the tool you are testing. If you see a request, check the domain. If it points to an extension you installed rather than the tool's own site, that is your extension, not the tool. To avoid the confusion entirely, run the test in a private or incognito window, which disables most extensions by default.
What this check does not prove
Be clear with yourself about the limits, because a partial check treated as a full audit is worse than no check. Watching the network panel confirms one thing: whether your input is transmitted from your browser during the actions you tested. It does not tell you what a server does with data it does receive. It does not confirm whether transmitted data is stored, sold, or used to train a model. It does not cover code paths you did not trigger. A tool can transmit data for a legitimate reason and still handle it responsibly, and a tool can send nothing in your test and still have other issues.
So use this for what it is. It is a fast, concrete way to verify a specific and common claim, that a tool runs locally and keeps your input on your device. When a tool makes that claim, this is how you hold it to it. For everything else, the transmission question answered here is the start of the conversation with the vendor, not the end.
Why this matters for legal work
The reason to check is not paranoia. It is that client information carries obligations that follow it wherever it goes. Before you paste anything privileged or confidential into a tool you did not build, you are entitled to know whether that information stays on your machine or travels to someone else's. Most people never check because they assume they cannot. You can. It takes two minutes, and it is the difference between trusting a claim and verifying it.