How to Verify That Your DNA File Never Leaves Your Browser (a 3-Minute Check With DevTools)

Open your browser's developer tools, switch to the Network tab, then generate a report. On Full Human Health you will see the generator module download once (about 40 MB), two small requests that reserve and complete a credit, and one analytics event naming the report type. Nothing the size of your DNA file leaves the page. The same three minutes test any other service.

The claim, and why it needs checking#

"Processed on your device" is a standard promise now. Counting ours, at least six raw-DNA tools make it in 2026: Genetic Lifehacks says the file never leaves your device, GenomeInsight says everything is processed inside the browser, Allelix (open source, AGPL-3.0) says genotyping data never leaves your machine, snp-browser matches the file in browser workers, and personal-genomics (MIT) runs locally. All five pages were checked on 14 October 2026.

A promise is not a proof, and code changes with every deploy. When we fetched GenomeInsight's home page on 14 October 2026, its HTML referenced Google Tag Manager, Google Analytics, Google Ads and Facebook Pixel scripts. That is not a DNA upload, and we did not test its analysis page, but a site can be honest about the file and still send plenty about you. The only way to know what a page sends is to watch it.

Open the Network tab and generate a report#

1. Sign in on the account page and select your raw file (our download guide covers each provider). Do not click Generate yet.
2. Open the developer tools: F12, or Ctrl+Shift+J (Cmd+Option+J on a Mac) in Chrome and Edge, then click the Network tab, per Chrome's documentation; in Firefox, Ctrl+Shift+E (Cmd+Option+E) opens the Network Monitor directly.
3. Tick "Preserve log" (Chrome) or "Persist Logs" (Firefox) and clear the list.
4. Click Generate.

Four things appear, in order:

• One large download. A .wasm file from our own domain: the generator, Rust compiled to WebAssembly, with the catalogue inside. Roughly 40 MB uncompressed; the Size column shows the amount transferred, which may be smaller if compressed. It is a download, cached for next time.
• POST /api/generations/reserve. Open its Payload (Chrome) or Request (Firefox) tab: the body is {"reportId":"..."} and nothing else.
• POST /api/generations/<id>/complete. No body. It marks the credit as used once the PDF exists on your device.
• One analytics event to /_vercel/insights on our domain, named report_generated: report type, PDF language, the provider you picked, and the duration in milliseconds. No file name, no genotype.

Sort by Size. The only large row is the download; a raw export is tens of megabytes and would sit at the top if anything carried it. No Google script runs here: our advertising tag is excluded from the sign-in and account pages. Stripe appears only as a redirect when you buy credits, before any file is open. A failed generation adds one POST /api/generations/<id>/fail, without a body, and the credit comes back, plus a generation_failed event carrying the report type and the stage that failed (reserve, generate or complete).

Run the same check on any other service#

Same procedure, one rule: run it on the page that opens the file, not the home page. An upload is easy to spot: a POST or PUT about the size of your file, often multipart/form-data, often to a storage host or a path containing "upload". Chunked uploads show as several requests of a few megabytes; the WS filter shows WebSocket connections.

Some services upload by design and say so. Promethease needs the file on its servers and, according to its privacy page, deletes it once the report is delivered; it stopped storing files on 8 April 2025 (checked 14 October 2026). The problem is the tool that says "on device" and uploads anyway. One limit and one addition: a clean tool can change tomorrow, so repeat the check after updates; and open-source tools such as Allelix and snp-browser also let you read the code. Ours is not public yet, so for us the traffic is the evidence.

What we do store, and why#

Our servers hold the name and email address you typed at sign-up, a password hash and your sign-in sessions, your credit balance and Stripe payment records, and for each generation the report type, status and timestamps. Credits need an account, refunds need a record of what failed, and Stripe needs an email for the receipt. We never receive the file, the genotypes, the PDF or the file name. A credit is reserved before the build so that a failed one is refunded automatically. The security page lists every service we use and how long each record is kept; the methodology page explains what the generator does with the file in memory.

What a Content Security Policy would add (we do not have one yet)#

A Content Security Policy is a response header. Its connect-src directive restricts which URLs a page's scripts may contact through fetch, XMLHttpRequest, WebSocket, EventSource and sendBeacon, as MDN documents. Limited to our own domain and Stripe, it would make the browser itself refuse to send data anywhere else, even for a compromised dependency or a future bug.

We do not send it today: curl -I https://www.full-human.health/en-US returns an HSTS header and no Content-Security-Policy (checked 14 October 2026). The allow-list must keep Stripe Checkout, sign-in and analytics working, and needs testing first; it is on our list. It would be a second lock, not a replacement, because a policy allows our own domain and only the Network tab shows that even we do not receive the file. No third-party audit exists yet either. Our security.txt gives researchers a contact; the about page says who answers.

FAQ#

Does the Network tab show everything a page sends?

It records every HTTP request, WebSocket message and beacon the tab makes, including those from scripts and workers. It does not show what a browser extension sends on its own, so use a private window, and it only records while open, so keep it open for the whole generation.

Why does the page download about 40 MB?

The generator is Rust compiled to WebAssembly and carries its catalogue and the PDF renderer; the health catalogue alone holds 23,220 associations. It is large for the same reason your file never has to go anywhere: the catalogue comes to you. Your browser caches it, so later reports skip the download.

Can I cut the connection during generation?

Not for the whole run today. A credit is reserved before each report and completed after it; both calls need a connection. If completion fails, the reservation expires after 60 minutes and is refunded on your next visit. Reserving a credit before you go offline and completing it when you reconnect would let the whole run happen offline; we have not built that.

What exactly is in the analytics event?

The event name, the report type, the PDF language, the provider you picked and the duration in milliseconds, plus the page path and script version. Like every request it carries your IP address and browser string; Vercel derives a country, a browser and OS label and a visitor hash discarded after 24 hours, per its privacy page (checked 14 October 2026). No cookie, no file name, no genotype.

Is "runs in the browser" the same as "private"?

No. A page can handle your file locally and still send your identity and behaviour to advertising networks from the same tab, and the account behind it keeps what you typed in. Privacy is what the file-handling page sends, what the account stores and which law applies. Ask every tool for all three.