How this thing opens a 4 GB file in a browser tab

Most online CSV tools are a form that uploads your file to a server, which does the real work. This one isn’t — there is no server component at all — so this page owes you an explanation of how a browser handles files that make desktop spreadsheets give up, and how you can check the privacy claim rather than trust it.

Step 1: index, don’t load

When you drop a file, nothing copies it anywhere — the browser holds a reference to the file on your disk. A background worker then makes one streaming pass over it and records the byte position where every row starts. That index is tiny (about 4 MB per million rows), and it has to be built carefully: a newline inside a quoted CSV field does not end a row, so the scanner tracks quoting state byte by byte — the difference between a correct viewer and one that shreds your address column.

Files up to 256 MB are kept in memory after that pass; bigger files (up to 4 GB) stay on disk, and any row is fetched on demand by slicing exactly its bytes. That’s why the row count for a 2 GB file appears in seconds: the work is one sequential read, not a load into a spreadsheet grid.

Step 2: render 40 rows, not 4 million

The grid only ever creates DOM for the rows and columns in your viewport — around 40 rows, re-rendered as you scroll. Row space maps to scrollbar pixels directly up to about 400,000 rows; beyond that the scrollbar is proportionally scaled (browsers cap element heights, so a 10-million-row grid can’t literally be 300 million pixels tall). Cell text is exactly what the file contains: no type coercion, no date guessing, no “helpful” reformatting.

Step 3: every operation is a streaming pass

Search, filters, sort, dedupe, column stats and exports all work the same way: read the file in ~4 MB chunks, parse rows, do one thing per row, and keep only compact results (matching row numbers, running statistics, output chunks). A filter over 5 million rows keeps a few megabytes of matching indices, not 5 million row copies. Sorting extracts just the key column, sorts row numbers, and reads rows back in order. This is the same architecture data pipelines use — applied to one file, in a tab, with a progress bar and a working Cancel button.

What the honest limits are

• 4 GB per file — the row index uses 32-bit byte offsets.
• ~1 GB decompressed for .csv.gz input, which must fit in memory.
• 100,000 rows per Excel export — .xlsx generation is memory-hungry, and Excel itself stops at 1,048,576 rows.
• 512 MB for splitting — parts are assembled in memory before zipping.
• Sorting a multi-million-row file takes real seconds — it’s a genuine sort, not a trick.

Verify the privacy claim in 20 seconds

Don’t take “files never leave your device” on faith — it’s checkable. Open your browser’s DevTools (F12) → Network tab, then load a file and run a filter or an export: you’ll see no upload requests, because none exist. Stronger still: load this page, switch off Wi-Fi or enable airplane mode, and then drop a file. Everything — parsing, cleaning, exports — keeps working, which a tool with a server-side component could not do.

The site is deliberately boring infrastructure: static files on a CDN, cookieless aggregate page-view counting, and a privacy policy short enough to actually read.