View and edit CSV files in a spreadsheet-like interface
CSV is a deceptively simple format. The spec (RFC 4180) fits on two pages: records separated by newlines, fields separated by commas, and fields containing commas, quotes, or newlines wrapped in double quotes with internal double quotes escaped as pairs. In practice, real-world CSVs violate every rule. Semicolon-separated files from European Excel exports, tab-separated files that still carry a .csv extension, mixed quoting conventions in the same file, BOM-prefixed UTF-8 that breaks non-UTF-8 parsers, ragged row lengths, commas embedded in unquoted fields, the parser has to be permissive because the producing tools were. This viewer uses a tolerant parser that handles all common real-world deviations and shows you the result in a sortable, searchable table. A typical mid-sized CSV (say, a 50,000-row export from a CRM) is 5-20 MB of text. Browser-based parsing of that size loads in 1-3 seconds on a reasonable laptop and renders the first screen of rows almost immediately; scrolling uses row virtualization so only visible rows are in the DOM. For larger files, the CSV equivalent of "small big data," a few million rows, the viewer handles them but loads progressively and shows row counts as parsing completes. Files over 500 MB are better handled by dedicated tools like DuckDB or pandas rather than any browser viewer, because browser memory limits start biting regardless of how efficient the parser is.
Initializing in your browser…
A vendor sent a 40,000-row export and you just need to scan and lightly edit it without launching a heavy spreadsheet app.
Opened
orders_export.csv (40,210 rows, 9 columns)
In the viewer
Sortable, searchable grid with frozen headers; edit a cell and re-export, all in the browser.
The file is parsed and virtualised so tens of thousands of rows scroll smoothly, with column sort and search to find records fast. Because it stays client-side, a customer export with personal data is never uploaded anywhere.
CSV is a deceptively simple format. The spec (RFC 4180) fits on two pages: records separated by newlines, fields separated by commas, and fields containing commas, quotes, or newlines wrapped in double quotes with internal double quotes escaped as pairs. In practice, real-world CSVs violate every rule. Semicolon-separated files from European Excel exports, tab-separated files that still carry a .csv extension, mixed quoting conventions in the same file, BOM-prefixed UTF-8 that breaks non-UTF-8 parsers, ragged row lengths, commas embedded in unquoted fields, the parser has to be permissive because the producing tools were. This viewer uses a tolerant parser that handles all common real-world deviations and shows you the result in a sortable, searchable table. A typical mid-sized CSV (say, a 50,000-row export from a CRM) is 5-20 MB of text. Browser-based parsing of that size loads in 1-3 seconds on a reasonable laptop and renders the first screen of rows almost immediately; scrolling uses row virtualization so only visible rows are in the DOM. For larger files, the CSV equivalent of "small big data," a few million rows, the viewer handles them but loads progressively and shows row counts as parsing completes. Files over 500 MB are better handled by dedicated tools like DuckDB or pandas rather than any browser viewer, because browser memory limits start biting regardless of how efficient the parser is.
Fix a few values in a CSV export right in your browser instead of launching heavy desktop software.
Visually inspect a CSV before feeding it into a pipeline or database import.
Inline editing writes changes back into an in-memory table representation; your source file is never modified. Export writes the edited table to a new CSV with consistent RFC 4180 quoting, every field containing a comma, newline, or quote character gets wrapped in double quotes with internal quotes doubled. This is usually cleaner than the source file, which may have had inconsistent quoting. The export can also switch delimiter, encoding (UTF-8, UTF-8 with BOM for Windows Excel compatibility, Latin-1), and line endings (LF, CRLF) if you need to match a specific downstream system's expectations.
One detail worth knowing about Excel and CSV: Excel's "Save As CSV" produces files that are technically compliant but disagree with RFC 4180 on some edge cases. Excel uses the system's decimal separator (comma in European locales, period in US/UK), which means a French Excel CSV has semicolon delimiters and commas as decimal points in numeric fields, the field "1,5" parses as a single numeric value in French Excel and as two fields in any parser expecting comma delimiters. The viewer detects this pattern by examining the first few rows and suggests the correct delimiter. Also, Excel always encodes non-ASCII as Latin-1 or the system default rather than UTF-8 unless you explicitly "Save As CSV UTF-8," which is why multilingual CSVs from Excel frequently show garbled characters in other tools, the viewer handles this by trying UTF-8 first and falling back to locale-appropriate encodings.
Sorting and search are implemented in the browser against the parsed representation, so they work on the full dataset regardless of size. Sorting a column of numeric strings uses natural numeric comparison (so "10" sorts after "9"not between "1" and "2" as alphabetic sort would). Sorting by date columns detects common date formats (ISO 8601, MM/DD/YYYY, DD/MM/YYYY) and sorts chronologically. For columns with mixed types, a common real-world case where "N/A" or empty strings appear in otherwise numeric data, the viewer sorts nulls/strings consistently at the top or bottom based on your preference rather than producing garbage order.
The viewer handles files up to several hundred megabytes depending on your browser memory. For very large datasets, consider splitting the file first.
No. Everything runs locally in your browser, your CSV data is never uploaded anywhere.
Rows and columns are parsed and transformed in memory in your browser. No record ever reaches a server.