Don't trust us. Verify it.

1. Open your browser's developer tools (F12) and select the Network tab.
2. Load Prism, then drop in a spreadsheet and work with it — profile it, chart it, edit it, export it.
3. Observe: no request containing your data is ever sent. The only network activity is the app downloading its own code from its own origin.

After your first visit, Prism works with no internet connection at all. Disconnect from the network, reload the page, and keep working. A tool that has no connection cannot upload anything.

Prism ships with a Content-Security-Policy that instructs your browser to block outbound requests to other servers. This isn't a promise in a privacy policy — it's a rule your own browser enforces against us. View the page source and find the Content-Security-Policy meta tag: connect-src 'self' means scripts on this page are barred from sending data anywhere else.

Working locally means your file has to fit in your browser, so here are the real measured numbers rather than a vague reassurance. Test file: a general-ledger export, 14 columns of invoice numbers, dates, customer details and amounts, run end-to-end from drop to rendered dashboard on a production build in Chrome.

Tested ceiling: 500,000 rows. Every view — dashboard, records, pivot, quality, column profile, computed columns — works at that size.

Parsing runs on a background thread, which is why the interface stays responsive throughout: the worst single frame delay we measured at half a million rows was 11 milliseconds. You can scroll, click and navigate while a large file loads.

Above roughly 600,000 rows a browser can no longer hold the sheet, and there is no clever way around it from inside a tab. Prism says so plainly and suggests splitting the file or exporting it as CSV — it will never show you a half-loaded file or a blank screen and let you assume it worked.