Case studies SplitForge

Twenty-seven tools. Zero uploads.

Role
Founder, sole developer
Period
2025 – present
Stack
TypeScript · React / Next.js · Web Workers · Streams API

Twenty-seven CSV and Excel tools that run entirely in the browser. The file never leaves the machine, because there is nothing for it to leave to.

The constraint

Excel stops at 1,048,576 rows. Every cloud CSV tool wants the file uploaded first, which is a non-starter for anyone handling customer, patient or payroll data. The brief I set myself was simple to state and hard to do: the file never leaves the machine.

That rules out a server. It also rules out the main thread, because parsing a multi-gigabyte file there would lock the tab. What is left is a Web Worker reading the file in chunks and handing results back as they finish.

The fix

Twenty-seven tools for splitting, merging, deduplicating, cleaning, validating, masking and converting CSV, Excel and JSON. Each one is a worker that consumes a file stream and produces an output file in memory, which the browser’s own download manager then writes to disk. There is no account requirement for the free tier and no retention anywhere, because nothing is ever received.

How it is built

  • Input. The File is read with the Streams API in fixed-size chunks so memory stays flat regardless of file size.
  • Processing. Every tool runs inside a dedicated Web Worker. The main thread only renders progress and results, which keeps the interface responsive during long operations.
  • Output. Results are assembled into a Blob and handed to a download link. Large outputs are chunked the same way inputs were read.
  • Shell. A React/Next.js front end hosts the tool catalogue, pricing and documentation. The tools themselves do not depend on the server once loaded.
  • Analytics. Site analytics (Google Tag Manager) measure page use only; file contents are never observable to the site.

Decisions that mattered

  1. No upload path at all, rather than “encrypted upload”. It removes an entire class of compliance questions and makes the privacy claim checkable from the network tab.
  2. Streams before features. The chunked reader was built before any tool, so every tool inherited the same memory ceiling.
  3. Workers per tool, not one mega-worker. Simpler to reason about, easier to ship a new tool, and a crash is contained.
  4. Honest limits. Performance scales with the visitor’s hardware and browser. The product says so rather than promising a number.

Result

A toolkit that handles files far beyond Excel’s row limit without a server, with zero data egress and zero server-side processing cost. Free tier of 25 operations a month; a Business tier for heavier use.

Evidence and limitations

What is independently checkable today: the product is live, the tool count and the client-side architecture are stated on the product site, and the absence of an upload endpoint can be confirmed in a browser’s network inspector.

What I do not publish here: my own benchmark figures. A benchmark run with machine specification and timing will be added when captured. The product screenshot in Fig. 1 carries SplitForge’s own marketing copy, including a tested-size statement; that is the product’s claim as shown on its site, reproduced unedited, and it is not a benchmark I am asserting on this page. No usage, customer or revenue figures are claimed.