Why We Run Everything in the Browser

The roster in the paste box

Your membership coordinator opens the renewal roster, copies a few hundred rows of names, emails, join dates, and payment histories, and pastes them into a free AI chatbot to draft this month’s lapsed-member emails. She is trying to save an afternoon. She has also just handed your members’ private details to a computer you do not own.

That exact moment is what every interactive on this site is designed around. Association staff handle the kind of data that would be a breach if it leaked: who your members are, how to reach them, what they paid, when they lapsed. Members handed you those details because they trust the association with them, and that trust is not yours to spend on a faster draft. So every tool on this site runs in the reader’s browser, with the data staying on the reader’s machine. This piece explains why that choice was made, what it actually means, and where it stops helping.

It also explains why the word “free” should make you pause. A free chatbot that runs on someone else’s servers still costs something. The payment is the data you feed it.

What leaves your machine when you press enter

A hosted chatbot is a program running on someone else’s computer. When you paste text into it, that text travels across the internet to their servers, where it can be logged, reviewed by staff, or used to train future models. You are trusting a privacy policy, which is a promise written by a company, and promises can change.

There is a sharper way to think about it, from a paper out of Arizona State University we read: for software that handles sensitive data, privacy should be a property of the architecture, not a policy promise (The Web-CLI: Verifiable Privacy for Tools, Models, and Inference Engines in the Browser). A policy says “we will not look.” An architecture that never sends the data anywhere does not need to say it, because there is nothing to look at.

That is the whole thesis. If the AI does its thinking on your computer, there is no server, no log file, no review queue, and no future model trained on your members. The data cannot leak in transit because it never travels.

What “in the browser” actually means

You already trust this pattern every day. When you open a spreadsheet, the math happens on your computer, and nobody calls that cloud computing. An in-browser AI works the same way: the web page downloads a small AI model once, like downloading a document, and from then on the thinking happens on your own machine.

The technical version is one sentence. The browser hands the page your computer’s graphics chip (WebGPU) or its regular processor (WebAssembly) so it can run the model locally, and the page is written so it never sends what you type anywhere. Researchers at Carnegie Mellon, Shanghai Jiao Tong, and NVIDIA built a framework that does exactly this and measured it at up to 80% of native performance (WebLLM: A High-Performance In-Browser LLM Inference Engine).

Two details are worth knowing. The model downloads once, and the download is the only part that touches the network. After that, the tool works without the internet at all. And when a tool on this site asks you to upload a file, the page reads that file on your machine. “Upload” sounds like sending, but here it only means the page can see the file. The page never forwards it anywhere.

How do you know a page is doing this and not quietly phoning home? There is a test anyone can run: disconnect your wifi and try the tool again. If it still works, your data cannot be leaving, because there is nowhere for it to go. The researchers call this the offline-first property, and we think it is the privacy claim that matters most, because it is a property you can test instead of a promise you have to take.

The honest limits: three machines, three routes

The tradeoff is real. A small model running on your machine is weaker than the giant models on a company’s servers, and it needs capable hardware to run well. So here is the honest map, by what your desk actually has.

If your machine is from roughly the last five years and you use a current Chrome, Edge, or Safari, try the browser route first. You can try the idea on this site right now: the local model lab runs a real AI model inside your browser, and nothing you type ever leaves the page. No subscription, no account, no per-message cost. For a team where nobody has a paid AI plan, that matters as much as the privacy.

If your laptop is older, the same kind of page may still run on the plain processor instead of the graphics chip: slower, but still local. Smaller models will answer more slowly and get more things wrong, so keep the tasks simple, ask for short answers, and check the output. If even that crawls, the model is too big for the machine, not too big for the idea; try a smaller one before you give up on the route.

If browser AI will not run on your hardware at all, the hosted chatbot is still on the table, but the data has to be scrubbed first. Our tutorial on checking member data before you paste walks through exactly which fields come out and what goes in their place. And whatever tier you use, free or paid, read the terms before member data goes in. The price of a tool you do not pay for is worth exactly one careful read.

The browser is not a spell

Here is the part people get wrong. “In the browser” is not a synonym for private. A web page can run in your browser and still send everything you type to a server; most of them do. The privacy comes from how the page is built, not where it runs.

So ask one question of any tool that claims to keep your data local: does it still work offline? If the answer is yes, the claim checks out. If the answer is no, or the vendor cannot say, treat the tool like any other hosted chatbot and keep member data out of it. The same principle is behind our facial-authentication gate, which runs its recognition in the browser so no face image ever leaves the page.

Picture a membership coordinator who needs first drafts of lapsed-member emails for everyone whose renewal lapsed in March. She opens the browser tool, pastes the roster columns into the page, and asks for drafts. The model reads the names and writes the drafts on her own machine. Nothing crosses the network, so there is nothing to log and nothing to breach. This is a teaching example, not a case study.

Keep the data, keep the responsibility

Running AI in the browser removes one specific risk: your members’ data sitting on someone else’s computer. It does not remove the others. A local model can still invent a wrong renewal date, still write a sentence you would not send, and still needs a human to read the output before it goes anywhere. The machine keeps your data. You still answer for what goes out under your name.