VisiData: a terminal spreadsheet for exploring tabular data

What VisiData solves, and who it is for

Opening a 200 MB CSV in a text editor tells you almost nothing. Opening it in a GUI spreadsheet is slow, and the file may not survive a round trip. VisiData takes a third path: it renders the file as a scrollable grid inside the terminal, with commands for sorting, filtering, frequency counts and column arithmetic. The README describes it as "a terminal interface for exploring and arranging tabular data", and the format list goes well past CSV: tsv, csv, sqlite, json, xlsx, hdf5 and others.

The audience is narrower than the format list suggests. This is for people who already live in a shell: data journalists checking a dump, engineers inspecting a SQLite file or a JSON export, anyone who pipes a command into a viewer. The README shows both directions of that workflow, `vd <input>` and `<command> | vd`. If your work happens in a browser or a shared workbook, the terminal constraint is a real cost, not a preference.

How the terminal grid and format loaders fit together

The repository layout separates the core from the loaders. The `visidata/` package holds the application, and `plugins/` holds extensions; `requirements.txt` lists the optional Python packages each format needs, one per line with a comment naming the format, for example `openpyxl>= 2.4 # xlsx` and `h5py # hdf5`. That is the mechanism behind the format support: VisiData itself is small, and the readers come from third-party libraries loaded on demand.

The consequence is that a format can be listed in the README and still fail on your machine, because the loader's package is missing. The README addresses this directly: if VisiData reports `package X not installed` after you installed it, `vd` is running from a different environment than the one you installed into. It suggests checking `which vd` and then installing into that environment, with `pipx inject visidata X` as the pipx route. Treat the environment mismatch as the first thing to rule out when a format does not open.

The apps are also packaged inside the tree rather than as separate downloads. `Makefile` has dedicated targets for two of them, `test-vgit` and `test-vdsql`, which run VisiData in batch mode against test files. That tells you the project treats these apps as part of the same codebase, not as external add-ons.

Installing VisiData and opening a first file

The README gives the PyPI route first, and it is the shortest path if you already manage Python environments.

pip3 install visidata

If you would rather not install it permanently, the README offers a one-off run through pipx or uv. This starts VisiData without adding anything to your PATH.

pipx run visidata          # or: uvx visidata

For a permanent install that adds `vd` to your PATH, the README gives the pipx and uv equivalents. Either command leaves you with a `vd` executable.

pipx install visidata      # or: uv tool install visidata

Excel and HTML support need extra packages, because those loaders are not bundled. The README shows how to pull them in at install time, and how to add them to an existing pipx install afterwards.

pipx install visidata --preinstall openpyxl --preinstall lxml
# or: uv tool install visidata --with openpyxl --with lxml
pipx inject visidata openpyxl lxml

Once installed, the usage pattern is two lines in the README. Point it at a file, or pipe data into it.

vd <input>
<command> | vd

What you should see is the data in a full-terminal grid. `Ctrl+Q` quits at any time, which is worth remembering before you start exploring the command set. The README points to `Ctrl+H` for the quick reference inside `vd`, and notes that hundreds of commands and options exist beyond the two usage lines. For a guided walkthrough rather than a reference, the README links Jeremy Singer-Vine's "Intro to VisiData" tutorial.

Where VisiData is the wrong tool

The interactive model is the limitation. VisiData is built around keystrokes against a live terminal, and the README's own description of the project is a spreadsheet multitool, not a library. If you need a repeatable transformation that runs in CI, the natural move is to write the logic in pandas or SQL and keep VisiData for inspection. The README does not present VisiData as a scripting engine for pipelines, and the Makefile's batch targets exist to test the bundled apps, not to advertise headless operation as a general feature.

Platform support is narrower than the terminal-first pitch implies. The README lists Linux, OS/X, or Windows (with WSL). Native Windows is not in that list, so a Windows user needs WSL first. For a tool whose appeal is fitting into an existing shell, that is a reasonable boundary, but it rules out environments where WSL is not available or not permitted.

The Python version floor is 3.8+, and the optional dependencies carry their own floors. In `requirements.txt`, pandas has two markers, `pandas>=1.5.3; python_version >= '3.11'` and `pandas>=1.0.5; python_version < '3.11'`, and `pyarrow>=14.0.1` is gated on 3.8+. On an older interpreter, the set of formats that actually work shrinks. That is a packaging detail, but it decides whether your Excel or Parquet file opens at all.

VisiData compared with a GUI spreadsheet and pandas

Against a GUI spreadsheet, the difference is not cosmetic. A GUI spreadsheet holds the whole workbook in memory as an editable document and expects you to save it back. VisiData opens a file as a view, and the operations it is known for, sorting, filtering, frequency tables, are applied to that view rather than to a saved document. The upside is that a large file opens quickly and you never risk overwriting the source by accident. The downside is that the familiar spreadsheet affordances, multiple sheets side by side, formatting, formulas in cells, are absent or handled differently.

Against pandas, the difference is the interface. pandas gives you a Python API and expects you to write code before you see anything; VisiData gives you the data immediately and lets you decide what to do after looking at it. For exploratory work on a file you have never seen, that ordering matters. For a transformation you will run a hundred times, pandas is the better home for the logic. The two are not exclusive: the README's format list includes the same sources pandas reads, and the requirements file lists pandas itself as an optional dependency for Stata `.dta` files, so VisiData can sit in front of a pandas workflow as the inspection step.

Maintenance, releases and the GPLv3 licence

The repository is not archived, and the last push was on 2026-09-17. Releases are not frequent: v3.4 on 2026-07-01, v3.3 on 2025-09-08, v3.2 on 2025-06-15. The v3.3 tag is annotated "bugfixes mostly", which suggests the maintainers treat minor releases as fixes and reserve larger changes for major ones. The default branch is `develop`, and the README warns that installing from it comes with "no warranty expressed or implied"; the release channel is the safer default for anything you depend on.

Upgrade cost is dominated by the optional dependencies rather than by VisiData itself. Each format pulls in a library with its own release cadence, and the version markers in `requirements.txt` mean a Python upgrade can change which of those libraries are eligible. The README's troubleshooting note about `package X not installed` is the practical symptom: after an upgrade, `vd` may resolve to a different environment than the one holding your format packages.

The licence is GPLv3, and the README scopes it to "code in the `stable` branch of this repository, including the main `vd` application, loaders, and plugins". That scoping is worth reading literally. If you redistribute VisiData, or build on it, the GPLv3 obligations apply to that code, and the README does not offer a separate commercial licence. This is a description of the stated terms, not legal advice; check with counsel if redistribution is part of your plan.

Editorial conclusion

Adopt VisiData if you routinely inspect CSV, TSV, SQLite, JSON, Excel or HDF5 files from a shell and want to sort, filter and reshape without writing a script. Do not adopt it if you need a GUI, a shared workbook, or a stable Python API for production pipelines; the README points to the plugin API guide but the tool is built around interactive use. Verify two things before rolling it out: which Python environment `vd` resolves to, because format packages must be installed into that same environment, and whether GPLv3 redistribution terms fit how you ship it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. saulpw/visidata on GitHub