Drop a CSV file here
Any size — .csv, .tsv or .txt. Click to browse instead.
Open the CSV Excel refuses — gigabytes, millions of rows — and browse, sort, filter and query it. The file is read off your disk and never uploaded.
The file is read off your disk and stays there. Parsing, the database and every query run inside this tab — no upload, no account, no copy on a server.
Drop a CSV file here
Any size — .csv, .tsv or .txt. Click to browse instead.
Excel stops at 1,048,576 rows, and long before that it stops being usable: a 900 MB export opens for twenty minutes and then falls over. This page takes the same file and makes it browsable in seconds. The CSV is streamed off your disk a chunk at a time, parsed as it goes, and loaded into a real SQLite database running as WebAssembly inside the tab — so the limit is your free disk space, not your RAM and not a row count someone picked in 1985.
Nothing is uploaded. Every competitor that will open a file this size wants it on their servers first, which for a customer export, a payroll dump or a database extract is the one thing you cannot do. Here the File handle is passed to a Web Worker, read with file.stream(), and written into a database in the origin-private file system. There is no upload endpoint on this site to send it to, even by accident, and the scratch database is wiped when you leave.
The table you scroll is a window, not the file. Only the rows under your cursor are fetched — about sixty at a time, with LIMIT and OFFSET against the imported table — so row nine million arrives as fast as row nine. Column types are detected during the import (integer, real, boolean, date, text) using rules that refuse to guess: 007 and 0912345678 stay text so phone numbers survive, 31/07/2026 is not treated as a date because nobody can tell it from July 31st, and an integer too large for JavaScript stays text rather than being silently rounded.
Sorting, filtering and the SQL bar are all the same thing underneath: SQL against your own table. Column names are quoted properly, so a header containing a quote character does not break anything, and every value you type is sent as a bound parameter rather than pasted into the statement. The SQL bar itself is unrestricted — it is your database on your machine, so GROUP BY, joins against nothing, CREATE INDEX, whatever you need. Whatever the current view or query returns can be exported back out as CSV, streamed row by row so a ten-million-row export costs one buffer rather than ten million strings.
Bigger than your memory, because nothing is held in memory. The file is streamed and the rows land in a SQLite database file in the browser's origin-private file system, so the practical ceiling is free disk space and the storage quota your browser grants the site. A few gigabytes is routine; the import runs at tens of megabytes a second on a laptop.
No. It is read off your own disk by the browser, parsed in a worker thread on your machine, and written to a database that also lives on your machine. There is no account, no server, and no upload endpoint. Closing the tab is all the cleanup there is.
Two reasons, usually. A worksheet cannot hold more than 1,048,576 rows, so anything longer is silently truncated or rejected. And Excel loads the whole file into memory, so a multi-gigabyte export exhausts RAM long before it reaches that limit. This page has neither problem: there is no row cap, and the rows never all exist at once.
No. The delimiter is sniffed from the start of the file by testing comma, semicolon, tab and pipe and scoring how consistent the field count is across the first records — consistency beats frequency, so a prose column full of commas does not win against a semicolon that splits every row identically. The page tells you which one it picked and why.
Yes — pick the right character set from the dropdown and the file is re-imported with it. The encoding is detected automatically from the first 65,536 bytes, covering UTF-8, UTF-16, Big5, GBK, Shift_JIS, EUC-KR and Windows-1252, but a legacy CSV carries no encoding tag, so the guess can be wrong and is labelled as a guess rather than presented as fact.
That is the point of the query bar. The file is imported into a table you can name in a statement, and any SQL SQLite understands will run against it — aggregation, window functions, CREATE INDEX, subqueries. The result appears in its own table and can be exported as CSV.
They are reported, not repaired. Short rows leave the missing columns empty. Rows with more cells than the header has columns keep their extras in a separate column, re-encoded as CSV, so nothing in your file disappears — and the page tells you how many rows that happened to.
Never. The original is opened read-only and is never written to. The imported copy in the browser's storage is a scratch database rebuilt from scratch on every import and wiped when you come back, and exporting writes a new file rather than touching the old one.
Already have a .db or .sqlite file? Browse its tables, schema and queries the same way.
Turn a .vcf contact export into a CSV that a spreadsheet opens cleanly — and back again.
Not sure what you have? Identify a file from its leading bytes, not its extension.