CSV & Excel Viewer

CSV vs Excel: understanding the difference

CSV (Comma-Separated Values) and Excel (.xlsx) files look similar when opened in a spreadsheet application, but they are fundamentally different formats. A CSV is plain text — every row is a line, every field is separated by a delimiter character, and there is no formatting, no formulas, no multiple sheets, and no embedded images. You can open a CSV in any text editor and read it raw. This simplicity makes CSV the universal interchange format for data: it comes out of databases, APIs, export functions in SaaS tools, and command-line utilities without any special library.

Excel's .xlsx format, by contrast, is a ZIP archive containing a collection of XML files that describe cell values, styles, formulas, named ranges, multiple sheets, charts, and much more. The added richness is powerful for human-authored spreadsheets but adds complexity for programmatic processing. When a database or API offers both CSV and Excel export, developers almost always reach for CSV because it is simpler to parse and has no ambiguity about encoding. Excel files are more common when the spreadsheet was authored by a person and is meant to be shared with other people rather than consumed by a program.

The viewer handles both. For CSV it uses PapaParse, a browser-native parser that correctly handles quoting, escaped characters, and multiple delimiter types. For Excel it uses SheetJS (also known as xlsx), which can read both modern .xlsx and the legacy binary .xls format. Neither library sends your file anywhere — all parsing happens in JavaScript running in your browser tab.

Delimiters, quoting, and encoding

Despite the name, CSV files do not always use a comma as the delimiter. European locales commonly use semicolons because the comma is used as a decimal separator — so a number like 1,234.56 would be split into two fields if a comma were the delimiter. Tab-delimited files (TSV) are widespread in bioinformatics and data exports from tools like MySQL. Pipe-delimited files appear in legacy financial and logistics systems. The viewer auto-detects the delimiter by sampling the first few lines and picking the character that appears most consistently across rows. If detection is wrong you can override it manually.

Quoting is the mechanism that allows a field to contain the delimiter character itself. The CSV specification (RFC 4180) says any field that contains a delimiter, a double-quote, or a line break must be enclosed in double-quote characters. A literal double-quote inside a quoted field is escaped by doubling it: "". So a field containing the value She said, "hello" would appear in a CSV file as "She said, ""hello""". PapaParse handles all of this correctly, including the edge cases that trip up naive split-on-comma parsers.

Character encoding is another frequent source of pain. The modern standard is UTF-8, which can represent any Unicode character including Chinese, Arabic, emoji, and accented European letters. However, many legacy tools — particularly older versions of Excel on Windows — save CSV files in Windows-1252 (also called CP1252 or Latin-1 extended), a single-byte encoding that handles Western European characters but breaks on anything outside that range. When you open a CP1252 file in a UTF-8 environment, accented characters like é, ü, or ñ appear as garbled sequences like é, ü, or ñ.

A related quirk is the UTF-8 BOM (Byte Order Mark): a three-byte sequence (EF BB BF) that Excel prepends to UTF-8 CSV files it generates on Windows, to signal the encoding to Windows software. The BOM is invisible in most editors but can appear as a stray character at the start of the first field if a parser doesn't strip it. The viewer handles BOM-prefixed files correctly.

What it handles

The viewer uses PapaParse for CSV parsing (which handles quoted fields, escaped commas, and multiple delimiters correctly) and SheetJS for Excel files. Both libraries run entirely in the browser — your data never leaves your machine.

Classic CSV pitfalls

Even with a robust parser, data quality issues in the source file can cause confusing results. Knowing the most common pitfalls helps you spot them quickly when something looks wrong in the viewer.

Column statistics

Click on a column header to see statistics for that column: count, unique values, most frequent value, min/max (for numeric columns), and mean/median. This is useful for quickly auditing data quality — spotting columns with too many nulls, unexpected string values in numeric fields, or outlier values.

The null/empty count is particularly valuable in data audits. A column that should be mandatory (like a customer ID or an order total) should have zero empty values. Seeing that 12% of rows have an empty value in that column immediately tells you there is a data collection or export problem that needs investigation. Similarly, the unique value count for a column that should be a foreign key (like a status field) tells you how many distinct statuses exist — if you expect five but see eight, someone has been entering free-form text instead of selecting from a dropdown.

Viewing and inspecting without installing software

One of the most practical reasons to use a browser-based CSV viewer is avoiding the need for installed software. On a locked-down work machine where you can't install tools, on a friend's computer, inside a virtual machine, or in a CI environment where you're debugging an export — if you have a browser you have a viewer. No installation, no version mismatch, no license required.

Another common scenario is receiving a file from a colleague and needing to quickly verify its structure before importing it into a system. Questions like "does this export have the right columns?", "are there any empty rows at the end?", "what delimiter does this use?" can all be answered in seconds by dropping the file into the viewer. You get a structured table view, the column count, the row count, and immediate visual feedback — much faster than opening a terminal and running head -5 file.csv or waiting for Excel to start.

Privacy is another consideration. When you upload a file to an online tool that processes data server-side, you are sending potentially sensitive business data to a third party. With this viewer, the file is read by JavaScript in your browser tab and never transmitted anywhere. There is no server, no storage, no logging of your data. When you close the tab the data is gone. This makes it safe to use with confidential customer data, financial records, or proprietary product information.

Handling large files

CSV files with 50,000+ rows are common in data work. Rendering all of them at once would freeze the browser. The viewer paginates automatically — 100 rows per page by default, configurable up to 500. Search and sort still operate across the full dataset, not just the current page.

What does "large" mean in practice? A 10,000-row CSV with 20 columns of typical data is around 2–5 MB and loads in under a second on a modern machine. A 200,000-row file can be 20–50 MB and may take 3–5 seconds to parse, but the viewer streams the parse results so you start seeing rows while the rest of the file is still being processed. Files above 500 MB will challenge browser memory limits; for those use a dedicated tool like DuckDB, Pandas, or csvkit on the command line.

The search function deserves a note on performance. When you type in the search box, the viewer filters against every column of every row in the full parsed dataset — not just the currently visible page. For files with hundreds of thousands of rows this filter runs in JavaScript and may take a few hundred milliseconds. The result is debounced so the filter only fires after you stop typing, keeping the UI responsive. Sort operations are also full-dataset: when you click a column header the entire dataset is re-sorted in memory, then the first page of the sorted result is displayed.

Tips for clean CSV data

If you are generating CSV files — from a database export, a script, or an application — following a few conventions will prevent the pitfalls described above and make life easier for everyone who consumes the data.

One final tip: validate your CSV exports as part of your pipeline. Running a quick parse and row-count check after generating a CSV catches truncation bugs (where a large export silently stops partway through) and schema drift (where a column is added or removed). Dropping a sample of the output into this viewer is one of the fastest ways to sanity-check an export before it goes to a customer or downstream system.

Frequently Asked Questions