Your Data Never Leaves Your Browser — Here's Exactly How That Works

Almost every “AI, analyze my data” tool works the same way: you upload your file, it lands on a server, and their model runs against it in the cloud. That’s fine for a public CSV. It’s a non-starter the moment the file has customer records, salaries, patient rows, or anything you signed something promising to protect.

Curator is built the other way around. Your data is analyzed in your browser — it never gets uploaded. That’s not a policy or a promise about deleting things later; it’s the architecture. Here’s precisely how it works, and — because being honest about this is the whole point — exactly what does leave your browser and what doesn’t.

The browser is the computer

A modern browser can run real analytical engines locally, compiled to WebAssembly. Curator loads two of them into your tab:

• DuckDB (Wasm) — a full analytical SQL engine. Your file is read into it in the tab; queries run against it right there.
• Python + pandas (via Pyodide) — for the stats and modelling steps, also running entirely in the page.

When you ask a question, the generated code executes against your rowsin your browser and hands back the answer. The actual cells of your dataset — the names, the numbers, the diagnoses, the dollar amounts — are never sent anywhere. They live in the tab’s memory and disappear when you close it.

So what talks to the AI, then?

Here’s the honest part most tools gloss over. An AI still has towrite the code, and to write correct code it needs to know theshape of your data. So a small, deliberately value-free description goes to the model:

• the column names and types (e.g. age (number), region (text)) and the row count;
• a statistical profile — ranges, distributions, how many blanks — with no actual cell values;
• a few synthetic sample rows — fabricated stand-ins with the right shape, not real records;
• and the question you typed.

That’s the whole payload. The model sees enough to write SELECT region, AVG(salary) FROM … correctly, but it never sees a single real salary. The code comes back, runs locally on the real data, and the numbers are computed on your machine.

If even column names are sensitive, there’s a privacy mode that replaces them with neutral handles before anything leaves the page, and swaps the real names back in locally when the code runs — so the model works on col_3 instead of hiv_status.

Why this is different from “we encrypt your uploads”

Plenty of tools say your data is “secure” — meaning they upload it, then protect it on their side. You’re still trusting their servers, their retention, their breaches, their subprocessors. With in-browser analysis there’s nothing on their side to breach, because your rows were never there. The trust surface shrinks from “their entire cloud” to “the code that runs in your own tab” — and you can read that code, because Curator shows you every line it ran.

What we won’t claim

Being precise cuts both ways. Two things we deliberately don’t say:

• “Nothing ever leaves.” The column descriptions and your typed question do go to the model to write the code. Your data stays local; that metadata does not. We’d rather tell you exactly where the line is than round it up.
• “HIPAA compliant.” Because your question is free text, it could contain sensitive details, and that goes to a third-party model — which is a different legal bar (one that needs a signed agreement with the model provider). So a rule of thumb: put the question in plain, non-identifying terms (“average value by group,” not “…for patient Jane Doe”), and your actual records still never leave regardless.

The point

For most people analyzing something they’d rather not hand to a stranger’s server, that distinction is the whole ballgame: the AI writes the code, but your data is analyzed where it already lives. Nothing to upload, nothing to leak, and the exact code shown so you can check it.

You can see it for yourself with no account — drop a file into the workbench and watch it work without your data ever leaving the page. (Writing the code needs a quick call to the model, so you’ll want a connection for that; the analysis itself then runs on your rows, right in the tab.)