The short version: When you upload a file to most online tools, it travels to their server. With Sohovi, your file is loaded into your browser's memory and all processing happens locally on your device. Nothing is transmitted to our servers. You can verify this with your browser's developer tools — open the Network tab and watch what happens when you process a file. You'll see zero upload requests.
How Most Online Tools Work
The typical architecture for an online data tool:
- You select a file and click "Upload" or "Process"
- The file is transmitted to the tool's server via an HTTP POST request
- The server processes the file (runs the dedup, conversion, or analysis)
- Results are sent back to your browser
- Depending on the tool's retention policy, your file may be stored on their servers for minutes, hours, or indefinitely
This is efficient for the tool builder (server-side compute is cheaper and more powerful) but creates an obvious privacy problem: every file you process becomes temporarily — or permanently — in possession of a third party.
Sohovi automatically detects PII in your datasets — emails, phone numbers, SSNs — all processed client-side so your data never leaves the browser.
How Sohovi Works Instead
Browser-local processing via WebAssembly:
When you open Sohovi, your browser downloads the processing code. That code runs locally on your device using JavaScript and WebAssembly — the same technology that powers browser-based games, video editors, and code compilers. When you load a file:
- The file is read into your browser's memory using the File API
- All processing (profiling, deduplication, validation, PII detection) runs in your browser tab
- Results are rendered directly in your browser
- The file never leaves your device
Sohovi automatically finds every duplicate in your dataset — including near-matches — and shows you exactly which rows are affected.
The only network traffic Sohovi generates: loading the application itself (HTML, CSS, JS) and authentication. Processing requests generate no network traffic.
Why We Built It This Way
The GDPR problem: When EU customer data is processed by a third-party tool, that tool becomes a data processor under GDPR. Using a processor without a Data Processing Agreement (DPA) is a violation. Most free online tools have no DPA. Browser-local processing sidesteps this entirely — if the data never leaves your browser, no processor relationship is created.
The trust problem: We're building a data quality tool. Our customers' biggest pain point is data they can't trust. Asking them to trust us with their sensitive data files — and trust that we handle it correctly, store it securely, delete it promptly — adds a new trust problem on top of the one we're solving. Browser-local processing eliminates this.
The compliance problem: Healthcare data (HIPAA), financial data, personal data of Indian customers (DPDP Act), California residents (CCPA) — these all have different rules about third-party data sharing. Browser-local processing is compatible with all of them because the data stays on the user's device.
Verifying It Yourself
We encourage skepticism. Here's how to verify the claim:
- Open Sohovi in Chrome or Firefox
- Open Developer Tools (F12)
- Click the Network tab
- Upload a file and run the profiler or dedup
- Watch the Network tab during processing
You'll see network requests for static assets (JavaScript files) but no data transmission requests. The file bytes never appear in any network request payload.
This is the strongest form of transparency we can offer: the claim is technically verifiable by any user at any time.
The Trade-Offs
Browser-local processing isn't free. The trade-offs:
Speed: Server-side processing can use more powerful hardware. For very large files (500k+ rows), browser-local processing is slower than server-side. We've optimized significantly using WebAssembly, but there's a fundamental ceiling.
Features: Some features require server-side components — user accounts, saved profiles, team collaboration, and scheduled monitoring all involve our servers (though never for data processing, only for metadata and settings).
File size limits: Your browser has a finite memory budget. Files larger than your device's available memory can cause issues. For most business use cases (files under 100MB), this isn't a practical constraint.
Frequently Asked Questions
Q: Does this mean Sohovi has no servers? No — Sohovi uses servers for account management, saved settings, authentication, and the application itself (serving the HTML/JS files you download to your browser). What we don't use servers for is processing your data. The distinction is important: our servers never receive your file.
Q: If our processing is browser-local, what do we get from having an account? Your validation rules, saved quality profiles, column configurations, and team settings are stored (on our servers, encrypted) so you don't have to recreate them. Your data files are not.
Q: Can I use Sohovi offline? After the initial application load, most processing functionality works without a network connection because it runs locally. You'd need network access to log in, sync settings, or export shared reports.
Q: Is this the same as how OpenRefine works? Architecturally similar — OpenRefine also runs locally (as a Java process on your machine) and processes files locally. The difference: OpenRefine requires installation; Sohovi runs in your browser without installation.
We built Sohovi this way because we believe privacy and utility shouldn't be a trade-off. Your customer data belongs on your device — not on someone else's server. Verify it yourself: open the network tab and watch.