A spreadsheet gives up at 1,048,576 rows. A text editor tries to load four gigabytes into memory and takes your afternoon with it. CSV Viper indexes the file once and then never reads more than a screenful — so the size of what you opened stops being your problem.
1.2 GB · 8,459,121 rows · indexed in 2.6 seconds
You already know what happens. You double-click a vendor export, wait four minutes, and get told the file is too large — or worse, get shown the first million rows with no warning about the rest.
Excel's row limit is a hard stop. An 8-million-row list opens as an 8-million-row list minus 7 million rows, and nothing on screen says so.
Loading the whole file into memory to show you forty lines of it is a strange trade, and on a 4 GB export it is one your machine loses.
Anything that samples the head of the file will tell you the column types are clean, right up until row 4,000,201 proves otherwise.
One pass over the file records where each row begins. After that, showing row 8,412,006 is one seek and one small read — exactly the same work as showing row 3. The size of the file stops entering into it.
An offset for every row costs eight bytes a row — 80 MB of index for a 10-million-row file, which has to be built, written, read back and held in memory. So only every Nth offset is kept, with N sized so the forward read from a checkpoint is about 64 KB.
This is the failure that costs you a case. A viewer that splits on newlines shows every row after the first multi-line note shifted by one — silently, plausibly, with the phone number now sitting under the wrong name.
Vendor files arrive in vendor order. The column you care about is the fourteenth one, and you scroll sideways to it four hundred times a day. Drag the header and it moves — and it stays moved.
Grab a header, drop it where you want it. A pink line shows where it will land.
Pin the phone number or the ID and it stays put while the other ninety columns scroll past.
A vendor's forty internal tracking fields do not have to be on your screen.
Call c_fname_1 what it actually is. The new name is what the export writes.
Double-click a header edge and the column becomes exactly as wide as what is in it.
Open the same file next week and the fields are where you left them. Nothing is written beside your data.
One forward pass writes a new file with the columns as shown, minus the hidden ones. Size is irrelevant.
Double-click any row to read it one field per line — the only sane way to read a 90-column record.
One file: 1.2 GB of lead data, 8,459,121 rows, 16 columns, 1,691 of them carrying newlines inside quoted fields.
Measured on an NVMe SSD. On an external USB disk the same work is bounded by what the disk can hand over — the index pass reads the file once and nothing more, which is the least any tool could read.
Real exports are not RFC 4180. They are whatever the vendor's script produced at 3 a.m., and a viewer that only reads clean CSV is a viewer you cannot use.
One unpaired quote character makes everything after it look like a single enormous field, and the row count silently collapses. CSV Viper catches it two ways — an odd number of quote characters across the whole file, which valid CSV cannot produce, or a single row measured in megabytes.
Then it says so, in a bar above the grid, with one button to re-read the file treating quotes as ordinary text. It is never applied for you: a file with a genuinely huge field would be damaged by that "fix", so the decision stays with the person who can tell the difference.
It runs on your machine, reads files by path, and has no outbound network call anywhere in it. There is no account, no cloud, and nothing to upload.
A browser upload would copy four gigabytes through memory before anything could start. Pointing at the file instead is why the first screenful is instant — and why the file stays where you put it.
No telemetry, no update check, no licence ping. Unplug the network and it behaves exactly the same way.
Index cache, column layouts and recent files live in your own AppData folder. Read-only shares and locked-down drives are read, never written to.
This started as a bad afternoon. A vendor sent an export too big for a spreadsheet and too awkward for a text editor, and the column that mattered was the fourteenth one — so the job became scrolling sideways, eight million times.
Everything here is a decision made while actually looking at that file. The index is checkpointed because building an 80 MB one was slow. Quote parity is tracked because the first version got the row count wrong and looked completely convincing while doing it. The broken-quoting warning exists because a file lied and nearly got away with it.
There is no sorting, because sorting a four-gigabyte file honestly needs a second index and nobody should pretend otherwise. There is no editing, because it is a viewer. What it does, it does at the speed of your disk.
No trial that expires, no row limit that appears at the worst moment, no account, no upsell inside the program. It is a finished tool given away finished — because the fastest way to show you what PinkViper Labs builds is to hand you something that works.
The cloud ones are cheapest for a month and most expensive by March — and every one of them needs the file uploaded before it can show you a single row. This one reads it where it sits, and asks for nothing.
CSV Viper came out of a much bigger problem: what to actually do with a file that size once you can finally see it.
The heavy machinery. Carrier filtering, de-duplication and cleaning for multi-gigabyte phone lists, with the paid lookups kept for last so you are not billed for numbers you were going to throw away.
◈Everything else built here — all of it local-first, all of it made because the existing tool did the job badly.
Point it at the biggest file you have. It will be on screen before you have finished reading this sentence.
Windows 10 / 11 · 64-bit · free · no account · no upload