In short: RowSlice's CSV viewer opens a CSV of any size inside your browser and shows you the rows — 100 at a time, with a jump straight to any row number and a search across one column or the whole row. It reads the file once to record where the rows begin, then reads back only the part you asked to see, so the memory it uses is the same for a 40 GB file as for a 40 KB one. Nothing is uploaded and nothing is written. It is a reader rather than a spreadsheet: there is no cell editing, no sorting and no formulas.
How to Open a Large CSV File in Your Browser
- Choose or drag in the CSV file. It is read from your disk instead of uploaded, so nothing has to be sent anywhere first.
- Check the preview of the first rows. If the columns look wrong, set the Delimiter or Encoding yourself under Advanced Options, and untick First row is a header if your file has none.
- Press Open the File. The file is read from beginning to end once, about 4 MB at a time, with the row count climbing while it works.
- Page through the rows, type a row number to jump to it, or search for a value.
What You Can Do Once It Is Open
The summary gives you the file in one line — how many data rows, how many columns, how big, which encoding and which delimiter — and the header row gives the columns their names. Under it are the rows themselves:
- Page through them, 100 rows at a time, forwards or back.
- Jump to a row number. Row 8,000,000 arrives as quickly as row 8, because neither one is reached by scrolling through everything in front of it.
- Search for text in one column or anywhere in the row.
Values are shown as your file wrote them and are never reinterpreted on the way to the screen. 00742 keeps its zeros, a 19-digit order reference keeps its last four digits, and a quoted value holding a comma or a line break stays one value instead of spilling into the next column. That is worth looking at before an import, because it is exactly where Excel would have changed both without saying so.
Seeing the file is usually the step before doing something to it, and what you see decides which tool comes next. Column names and a screenful of values, and the question becomes what the whole file looks like — the CSV analyzer counts and profiles every column. A search that found 40,000 rows worth keeping, and the question is how to get them out — filtering writes them to a new CSV. Rows that are plainly broken, or an import that has already failed once — the validator lists the rows at fault and can save them to their own file. The same export as last month, and the question is what moved — comparing the two files on an ID column reports the rows added, removed and changed.
How It Opens a File Excel Cannot
Excel puts rows on a sheet, so the rows have to fit: 1,048,576 of them, and in practice rather fewer before the machine gives up working out the type and formatting of every cell. A browser cannot hold 2 GB of rows either. The way round is not to hold them at all, and it takes two steps.
The first is one pass over the file, which is the wait you see after pressing Open the File. The file is read about 4 MB at a time as raw bytes — nothing is decoded and no row is kept — and those bytes are walked with the same rules the CSV parser uses: a quote at the start of a field opens a quoted value, a doubled quote inside one is an escaped quote rather than the end of it, and a line break ends a row only when no quote is open. That last rule is why the row numbers here are record numbers rather than line numbers. Every so many rows, one number is written down: the byte at which that row begins.
How often is decided by the file rather than guessed from its size. The table of positions never holds more than 200,000 entries, so when it fills up the viewer throws away every other entry and carries on recording half as often. Small files end up indexed row by row; huge ones land on the widest spacing they actually need:
| Data rows in the file | Positions recorded | Gap between them | Rows parsed to reach any row |
|---|---|---|---|
| 200,000 | 200,000 | Every row | None |
| 10,000,000 | 156,250 | Every 64th row | At most 63 |
| 100,000,000 | 195,313 | Every 512th row | At most 511 |
| 1,000,000,000 | 122,071 | Every 8,192nd row | At most 8,191 |
Each position takes eight bytes, so a completely full table costs 1.6 MB — for a file of any size at all, and less whenever it is not full. That fixed ceiling is the whole trick: what grows with the file is the spacing, not the memory.
The second step runs every time you ask for rows, and it is quick. To show the rows from 8,000,050 onwards in that 10-million-row file, the viewer looks up the nearest recorded row at or before it — a gap of 64 makes that row 8,000,001 — asks the browser for the file starting at that byte, parses forward the 49 rows in between, and shows the 100 you wanted. A few kilobytes are read out of gigabytes and the rest of the file is never touched. The first slice is sized from the file's own average row length and grows if the rows turn out to be longer than that, so the reading stays in proportion to the page rather than to the file.
Nothing else is held. The only things in memory are that table of positions and the rows currently on screen. Nothing is uploaded, because the file is read from your own disk by code running in your browser, and the page keeps working with the connection switched off once it has loaded. Nothing is written either — no copy, no cache, no result file — so unlike the tools here that save their output, the viewer needs no free disk space and no room in your browser's storage allowance. Tested in current Chrome, Edge and Firefox on Windows; Safari and macOS are untested. The guide to opening a large CSV file on a Mac covers the Terminal commands that show you the rows with nothing installed.
Our guide to opening a CSV that is too large for Excel sets out the six approaches in full — splitting it, Excel's Data Model, a large-file editor, DuckDB, pandas — and which one is right depends on what you need from the data. This is the one that needs nothing installed and no decision made first: open the file, look at what is in it, then choose from that list knowing what you are dealing with.
Searching a File Too Big to Search
A search here is a second pass over the file, not a lookup. The table of row positions knows where rows begin and nothing about what they hold, and a match can be anywhere, so every query reads the file from the first data row to the last. On a multi-gigabyte file that is the same wait as opening it was, and it is the honest cost of searching something no index covers.
You can look for text anywhere in a value or for a value that matches in full; upper and lower case are treated as the same unless you say otherwise; and the search can be pointed at one column or at every column in the row. Matches come back in file order with their row numbers, so anything you find can be jumped back to afterwards.
The two numbers you get back are not the same number, and the difference is the point. The list of matching rows is capped at 500 rows, because a list has to be held in memory, and a list of everything would undo the reason the tool works at all. The count is not capped: it is every matching row in the file, including the ones past the end of the list, and you are told when the list has been cut short. A search that reports 48,213 matches and shows you 500 is telling you something true about the file, instead of leaving you to guess whether you are looking at all of them.
What a search cannot do is arithmetic. It matches text, so 1200 finds the characters 1200 and nothing at all finds “amount over 5,000”. For number ranges, dates by prefix, or several conditions at once, use the CSV filter, which reads the same file and writes the matching rows to a new CSV. Searching tells you whether the rows are in there; filtering is how you take them away with you.
What It Does Not Do
This is a reader. If what you are after is a spreadsheet that copes with 50 million rows, it is better to know now than three clicks in:
- It does not edit. No changing a cell, no inserting or deleting rows, no Save and no undo. Your file is opened for reading and comes out of this byte for byte what it went in as.
- It does not sort. Rows are shown in the order the file holds them, and column headings do nothing when clicked.
- It has no formulas, pivot tables or charts. There is no arithmetic anywhere in it, not even a total of one column.
- It shows text, not types. Nothing is read as a number or a date on the way to the screen, which is why the values on it are still the values your file holds.
If a spreadsheet really is what the job needs, the route there is to make the file small enough to be one: split it into parts of up to 1,000,000 rows that each keep the header, filter it down to the rows that matter, take a few thousand rows out of it as a sample, or convert it to a real .xlsx workbook rather than opening the CSV in Excel and letting it rewrite values as it reads them.
Files It Cannot Open
One kind of file is refused outright: UTF-16. The refusal is deliberate, and it follows from the way the viewer works. Rows are found by their position in bytes, because a byte position is the only thing a browser can be asked to seek to in a file it has not read. UTF-16 spends two bytes on every character — the letter a is stored as 61 00, a line break as 0A 00 — so a row position that lands on the wrong byte of a pair puts every character after it half a step out of line, and the page decodes as mojibake. Showing you that would be worse than refusing, so the viewer stops and names the fix instead.
It catches these files whether or not they carry a byte order mark. With one, the mark states the encoding. Without one — and UTF-16 saved without a mark decodes as UTF-8 without complaining, which is why it usually goes unnoticed — the giveaway is that a quarter or more of the first 4 KB is zero bytes, which no single-byte CSV has. Convert CSV to UTF-8 rewrites the file, and the converted file opens here normally. UTF-8, UTF-16 and Windows-1252: which one is your CSV? covers how to tell which encoding you are holding, and why Excel cares.
Everything else opens. UTF-8 with or without a byte order mark, Windows-1252, and the other encodings offered under Advanced Options all share the property UTF-16 lacks: no part of a character in them can be mistaken for a line break or a quote, so a recorded byte position is always a safe place to start reading. The file does have to be plain text — .csv, .tsv, .txt or .tab — because an .xlsx workbook is a zip archive of XML and not a CSV at all.
Viewer, Analyzer or Filter?
Three tools here read a file too big for Excel and hand back three different things. Picking the wrong one usually means waiting out a full pass over a large file to find that it answered a question you had not asked:
| What you want | Tool | What you get back |
|---|---|---|
| To see the actual rows, and find a particular one | RowSlice CSV Viewer (this page) | Rows on screen, 100 at a time, with a jump to any row and a search across the whole file. No file is written. |
| To know what the file holds as a whole: how many rows, which columns, what the values look like | CSV Analyzer | A report — row, record and line counts, and a profile of every column, downloadable as a CSV. Your rows are not shown. |
| To keep the rows that match and work on those | Filter CSV Rows | A new CSV of the matching rows in their original order, and optionally a second file holding the rest. |
In practice they run in that order. Open the file to see what arrived, analyze it once the question turns into a number, then filter or split it to get a file you can work with. Two more sit beside them: the validator for a file an import has already rejected, and Convert CSV to UTF-8 for one whose characters arrived garbled. All of them read the file from your disk, in your browser, and none of them upload it.
Last updated .