Privacy

Private Local Data Analysis in the Browser

Understand the local processing model behind SQL for Files and how to work safely with sensitive CSV, JSON, and Parquet files.

Published 2026-05-02·Updated 2026-05-02

The local processing model

SQL for Files is built around client-side processing. Files are loaded into DuckDB WASM in your browser, SQL runs locally, and query results are rendered locally in the page.

Core privacy claim

The app does not upload your files, SQL queries, or query result rows to a backend service for processing.

What stays local

  • Added CSV, JSON, and Parquet file contents.
  • Tables created inside the browser DuckDB session.
  • Query text and query history stored by the app.
  • Saved table data when you choose local persistence.

Browser storage and persistence

When persistence is used, data is stored in browser storage such as IndexedDB. That is useful for continuing later, but it also means anyone with access to the same browser profile may be able to access saved work.

Use export/import backups when you want to move work between browsers, and clear browser storage if you do not want data retained on the device.

Sensitive data checklist

  • Use a trusted device and browser profile.
  • Avoid shared computers for confidential files.
  • Clear local data after one-off sensitive analysis.
  • Review exports before sending them elsewhere.
  • Prefer aggregated results when sharing outputs with others.

What local processing does not solve

Local processing reduces upload risk, but it does not replace device security, browser profile hygiene, file access controls, or organizational data handling policies. Treat the browser as part of your local workstation security boundary.

Continue in the editor

Open SQL for Files to add your own CSV, JSON, or Parquet files and try these examples locally in your browser.

Open editor