Query a CSV file with SQL

Spreadsheet filters run out of room quickly. A single condition is easy, two conditions are awkward, and the moment the question involves grouping, a subtotal, a rank within a category, or two files that need to be matched on a shared column, the answer is either a long afternoon or a database.

This is the database. SQLite compiled to WebAssembly, started empty in this tab, loaded with your file, thrown away when you leave. It is not a filter with SQL-shaped syntax on top: SELECT, JOIN, GROUP BY, HAVING, window functions, common table expressions and the standard aggregate and string functions all work, because it is the same engine that ships inside phones, browsers and aircraft.

Joining two files is the point

Load more than one CSV and each becomes its own table, named after the file, with the names and columns listed above the editor before you write anything. A file called orders.csv becomes orders, and 2024-returns.csv becomes t_2024_returns, because a table name cannot begin with a digit.

That is what makes this different from the filtering and sorting tools elsewhere on this site. Matching a list of order IDs against a list of refunds, checking which customers in one export are missing from another, or attaching a category from a lookup file to every row of a transaction log are all one query here and all genuinely painful anywhere else without either a database or a lot of copying between sheets.

Column types are decided from the whole column

This is where a query tool is easy to get quietly wrong. A CSV has no types: every value is text until something decides otherwise. If everything is loaded as text, then WHERE revenue > 1000 compares the characters rather than the numbers, and the answer comes back confidently wrong, because as text “9” is larger than “1000”.

So each column is typed from all of its filled cells, and every one of them has to agree. One “n/a” in a column of numbers makes that column text, which is deliberate and conservative: a column that is numeric for all but one row is a column where arithmetic would silently skip a row without saying so. Empty cells become null rather than empty strings, so COUNT and AVG ignore them and WHERE column IS NULL finds them.

Long integers stay text. Past about sixteen digits a number cannot be held exactly, and an account number, IMEI or order reference that comes back with its last few digits changed is worse than one that was never treated as a number. The types chosen are shown next to each column name after the first run, so the decision is visible rather than something to discover.

What it does not do

The result is capped at 50,000 rows, and the page says so when the cap is reached rather than handing back a short answer that looks complete. A query that runs for thirty seconds is stopped, because a join written without a matching condition multiplies the rows of both files and there is no way to tell that apart from a large file that is nearly finished.

Your data is never concatenated into the SQL. Rows are bound as parameters, so the only text that becomes a statement is the query you typed. Nothing is uploaded, no query is logged, and there is no account.