Loupe — CSV & JSON viewer with SQL

Open a big CSV as a real table, right in your editor. Then run SQL against it.

VS Code opens a 200 MB CSV as 200 MB of text. You get a wall of commas, no column alignment, and a search box. Loupe opens the same file as a sortable, filterable table — and gives you a query box.

Nothing is uploaded. Nothing is written back. The file does not leave your editor.

What it does

Open any .csv, .tsv, .jsonl or .ndjson file. Right-click → Open in Loupe, or set Loupe as the default editor for the type.

Look at it. Columns are typed from a sample, so numbers sort numerically and align right. Filter across every column as you type. Per-column summary: min, max, mean, distinct count, how many blanks.

Query it.

SELECT city, COUNT(*) AS n, AVG(amount) AS avg
FROM data
WHERE status = 'shipped' AND amount > 100
GROUP BY city
HAVING n > 10
ORDER BY n DESC
LIMIT 20

SELECT · WHERE · GROUP BY · HAVING · ORDER BY · LIMIT · OFFSET · DISTINCT · BETWEEN · IN · LIKE · IS NULL, with COUNT / SUM / AVG / MIN / MAX. Aliases from SELECT work in ORDER BY and HAVING. Export the result as CSV or JSON.

No JOIN, no subqueries — one file is open, so there is nothing to join to.

Why it is fast

Files are read in 4 MB slices through an incremental parser, and only the ~30 rows actually on screen are ever in the DOM. The row count in the document does not grow with the file.

Measured on 200,000 rows × 4 columns, filtering to a third and aggregating into 8 groups:

WHERE + GROUP BY + HAVING + ORDER BY + COUNT/AVG/SUM     77 ms

Parsing throughput is around 45 MB/s on a 17 MB file full of quoted newlines and escaped quotes.

Messy files

Real exports are not clean, so the parser is built for the mess:


Delimiters	Detected by column-count consistency, not by counting commas — a CSV full of prose still parses. Comma, tab, semicolon, pipe.
Encodings	UTF-8, Shift_JIS, EUC-JP, Windows-1252, Latin-1. Detected by decoding and scoring the result, so a Japanese CSV from a legacy system opens correctly instead of as `譁?蟄怜喧`.
Broken rows	Quoted newlines, escaped quotes, ragged rows, missing headers, malformed JSON lines. Kept and shown, not silently dropped.
Blanks	An empty cell is `NULL`, so `AVG` skips it instead of averaging in a zero.

The file does not leave your editor

This is the reason the extension exists, so it is enforced rather than promised:

The webview runs under a Content Security Policy with connect-src 'none'. It cannot open a socket, an XMLHttpRequest or a WebSocket. Not "does not" — cannot.
The build fails if fetch, XMLHttpRequest, WebSocket, sendBeacon, EventSource or a dynamic import() appears in any shipped script.
No telemetry, no analytics, no crash reporting, no accounts.
The extension opens the file read-only and never writes to it.

You can check this yourself: the source is MIT and the scripts are plain, unminified JavaScript inside the .vsix.

Limits

The file is held in memory, so the ceiling is what the editor's renderer process will give you — a few hundred MB of CSV in practice. Files over 256 MB are refused; raise loupe.maxFileSizeMB if your machine can take it. Past that size, use a real database.

A plain .json file has to be parsed as one value, so it is read whole. .jsonl streams.

Loupe is a reader. It will not edit or save your data.

Settings

Setting	Default
`loupe.maxFileSizeMB`	`256`	Refuse to open files larger than this.

Source

The parser, the type inference and the SQL engine are the same code that runs at kotebako.com/loupe, copied in verbatim at build time so the two cannot drift apart. 88 tests cover the parser and the SQL engine; 50 more cover the extension itself.

MIT — github.com/kotebako/loupe

Bugs and requests: github.com/kotebako/loupe/issues