In short: RowSlice's CSV analyzer reads a CSV of any size inside your browser and reports on the whole file: how many records, data rows and physical lines it holds, the columns and their names, the file size, encoding, delimiter and line endings, and for every column how many values are filled, how many are different, the shortest and longest, and how many of them Excel would damage. Nothing is uploaded. It is not a spreadsheet viewer: you see the first rows as a preview, and everything after that is a report rather than your rows on screen.
How to Analyze a CSV File
- Choose or drag in the CSV file. It is read from your disk instead of uploaded, so even a multi-gigabyte file is ready in a second.
- 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 Analyze File. The file is read from beginning to end, a few megabytes at a time, with a running row count while it works.
- Read the summary and the column report, and download the column report as a CSV if you want to keep it.
How Many Rows Does My CSV Really Have?
Three people count the same file and get three numbers. That is normal, and usually only one of the three is the number anyone wanted.
A CSV row is not a line of text. RFC 4180, the closest thing CSV has to a specification, allows a value to contain a line break as long as the value is wrapped in quotes, and any export carrying addresses, product descriptions or ticket bodies will contain some. Here is a file of three lines:
| Line | Text in the file | What it belongs to |
|---|---|---|
| 1 | id,note | Record 1, the header row |
| 2 | 1,"Left a note | Record 2 begins; the quote is still open |
| 3 | on two lines" | Record 2 ends |
That file is 3 physical lines, 2 CSV records and 1 data row. All three numbers are defensible; they answer different questions. The analyzer reports all three, which is what makes the disagreement readable:
| Number | What it counts | Who quotes it |
|---|---|---|
| Physical lines | Line breaks in the text, whatever they sit inside | wc -l, text editors, most split scripts |
| CSV records | Rows a parser sees, header included | Python's csv module, DuckDB, this tool |
| Data rows | Records minus the header, blank lines skipped | Import tools, and every summary on this site |
When lines and records come back equal, nothing in the file has a line break inside a value and the quick counting tricks would have been safe. When they differ, the gap is the extra lines swallowed by quoted values, plus any blank lines, which the report counts separately. Either way, a script that counted or split that file by lines has been getting it wrong, quietly, for as long as it has been running. How to count the rows in a CSV file goes through the same problem with wc -l, PowerShell, DuckDB and Python.
What the Column Report Tells You
The summary describes the file; the column report describes what is in it. There is one entry per column, worked out from every row rather than from a sample of the first thousand:
| What you get | What it answers |
|---|---|
| Filled and empty values | Whether a column is worth importing at all. A phone number filled in 4% of rows is a column to leave out of the mapping. |
| Distinct values | Three distinct values in two million rows is a category; two million is an identifier. Fewer distinct values than rows in a column that should be unique means duplicates. |
| Leading zeros and 16+ digit values | How much of the column a spreadsheet would change. See below. |
| Inferred type | What the values look like. Read it next to the examples rather than trusting it: one stray word in a column of numbers is enough to change the answer. |
| Shortest and longest value | Field limits in the destination system, and the one 4,000-character description that will fail the import. |
| Smallest and largest number | The range, without opening the file. A negative quantity or a price of 0 shows up here. |
| Up to three example values | What the data actually looks like, before you write any mapping rules. |
The header names matter as much as the figures when the same report arrives every month. Headers change over time — a column is renamed, two more are added in the middle — and comparing this month's column list against last month's takes a few seconds here, against a long afternoon once the rows have been loaded into the wrong fields. That comparison is of the shape of the two files. When the question is about the records instead — which rows were added, removed and changed since the last export — the two files have to be matched on an ID column rather than read side by side.
Finding the Values Excel Will Destroy
Two kinds of value are changed by a spreadsheet the moment a CSV is opened in one, and neither change is announced. A ZIP code, account number or product code written 00742 is read as the number 742 and loses its zeros. A number of 16 digits or more is rounded to 15 significant digits, so the last digits of a card number, IMEI or transaction ID are replaced by zeros and the cell is displayed as something like 4.5E+15. Save the file at that point and the original values are gone.
The column report counts both, per column, across the whole file, and the downloaded CSV carries them as their own columns, leading_zeros and long_numbers. A zero in each of those counts means the file is safe to open in a spreadsheet. Anything else tells you which column needs protecting and how many values are at stake, which is the difference between a problem worth chasing and one worth ignoring. Stop Excel removing leading zeros and stop Excel turning long numbers into scientific notation cover the import settings that keep them intact. The tools on this site copy rows as text and never interpret them, so nothing here makes the change in the first place.
Checking a File Before an Import
Most failed imports fail for a reason that was visible in the file beforehand, and four figures from the report cover most of them: the data row count against whatever row limit the destination has (see how to split a CSV to fit an import limit), the header names against the fields it expects, the empty count in each column that is required, and the distinct count in the ID column against the row count, which is how you find out that the key you are matching on is not unique.
The analyzer also counts what is structurally wrong: blank lines, and rows with more or fewer fields than the header. That is where its job ends, because the next question is no longer how many but which ones. The CSV validator answers that one: it runs the checks in full, lists the rows that fail them, and can save those rows to a separate CSV. It reports rather than rewrites, and points at the tools that fix each problem — Convert CSV to UTF-8, Remove Duplicates from CSV and Split CSV into Multiple Files.
Why Not Just Open It in Excel, or Run wc -l?
Excel is the right answer more often than people admit. If the file fits on a sheet and the machine has the memory for it, double-clicking it and reading the row number in the corner is faster than anything else, and you can sort and filter while you are there. It stops being the right answer at 1,048,576 rows: past that, Excel loads the first 1,048,576, warns that not all the data was loaded, and every figure you read afterwards describes the part it loaded. It is also the one tool here that changes values as it opens them, so the file you are profiling is no longer the file on disk.
wc -l orders.csv costs nothing and is fast. POSIX defines -l as writing the number of newline characters, so it is a line count in the strict sense: a file whose last line has no trailing line break comes back one short, and every quoted line break adds one. On the three-line example above it reports 3, or 2 without a final line break, where the answer is 1 data row. It is the right tool for a rough sense of scale and the wrong one for a number somebody is going to reconcile against.
On Windows, ([System.IO.File]::ReadLines('C:\data\orders.csv') | Measure-Object -Line).Lines is the fast line count: it streams, so memory stays flat, and unlike wc -l it counts a final line that has no line break. It is still a line count. (Import-Csv orders.csv | Measure-Object).Count does parse properly and gets the records right, but it builds a PowerShell object for every row, which is slow enough to notice on a file of millions. And the -ReadCount 1000 trick that circulates as a speed tip counts batches rather than lines: 2,000,001 lines come back as 2,001.
If DuckDB is already installed, SELECT count(*) FROM 'orders.csv'; is the best of both: a real parser, and nothing has to fit in memory. SQL also answers the questions this tool deliberately does not. The analyzer is for the case where you have a file, a browser and no appetite for installing anything: one pass gives you the record count, the line count, the column list and the per-column profile together, without the file leaving your machine. It sets no size limit of its own, because the file is read a few megabytes at a time. The one part of the run that takes memory in proportion to the file is Count exact duplicate rows, on by default, which keeps a 64-bit fingerprint of every different row and reaches 512 MB at its ceiling of about 33 million; untick it and a 10 GB file uses about as much memory as a 10 MB one. Chrome, Edge and Firefox on Windows are where it is tested.
Last updated .