csview and the CSV pager that gets CJK column widths right

The problem is column width, not speed

The README leads with being a high performance csv viewer with cjk/emoji support, and the feature list names the reason: correctly align CJK characters and emoji characters.

That is the real problem this tool solves. Terminal cells are not characters. A Latin letter occupies one cell, a Chinese character occupies two, and an emoji occupies two as well, often more depending on the terminal and the font. Most quick-and-dirty CSV printers count bytes or codepoints, so a column of Japanese text ends up with its table borders in the wrong places. The usual workarounds are to not care, or to pipe through a tool that does the arithmetic.

The output style is a box-drawn table with Unicode border characters, and the example in the README shows a car sales CSV rendered with aligned columns, quoted fields containing commas and embedded double quotes handled correctly.

The second example is more useful as a demonstration of the flags than of the data. It takes /etc/passwd through head and then into csview with -H and a colon delimiter:

$ head /etc/passwd | csview -H -d:

-H means there is no header row, and -d: sets the field delimiter to a colon. The result is a table of user records with the last field left empty where a record has no shell, which is the behaviour you would want.

So the tool has two faces. It is a table renderer with correct East Asian width handling, and it is a pager that fits that rendering into a terminal session.

What the feature list does and does not promise

The README's feature list is short, which is useful because it makes the boundary clear.

Small and fast, with a link to the benchmarks. Memory efficient. Correct alignment of CJK and emoji. Support for tsv and custom delimiters. Support for different styles, including markdown table.

That last one matters more than it looks. A markdown table style means csview output can be pasted straight into a README, a pull request description or a chat message without converting the box-drawing characters. For a tool whose whole output is ASCII art borders, having a plain-text alternative is a genuinely thoughtful addition.

What is not in the list is just as informative. There is no mention of sorting, filtering, selecting columns, computing aggregates, converting formats or writing output back to a file. csview is a viewer, not a query engine.

That is the meaningful difference from the general purpose CSV tools it is benchmarked against, and it is also where you should decide whether it fits. If your pipeline is cat something.csv and look at it, csview is the right size. If your pipeline is cut, sort and aggregate, you are looking for a different tool, and the benchmarks in the README are a reminder that the space of CSV command-line utilities is crowded.

Detailed usage is behind csview --help, and the repository has a completions/ directory with shell completion files, which tells you the flag set is substantial even if the feature list is short.

The benchmark numbers and what they measure

The benchmark section compares csview against three other tools, and the numbers are specific enough to be useful.

On small.csv, which is 10 rows, 4 columns and 695 bytes, xsv table runs at a mean of 2.0ms and column -s, -t at 1.3ms, while csview is at 0.3ms mean and 0.1ms minimum. csvlook is far behind at 148.1ms.

On medium.csv, 10,000 rows, 10 columns and 624K bytes, xsv table takes 0.031s, column takes 0.052s, csview takes 0.017s mean and 0.016s minimum, and csvlook takes 2.664s.

The memory column tells a consistent story. csview uses 2.4mb on the small file and 2.8mb on the medium one, xsv uses 3.9mb and 4.4mb, column uses 2.4mb and 9.9mb, and csvlook uses 27.3mb and 46.8mb.

Note what the large.csv case is. The README describes it as 1,000,000 rows, 10 columns and 61M bytes, generated by concatenating medium.csv 100 times, and then the table for it is cut off in the version of the README available here. So the headline comparison is only available for the two smaller files.

The pattern across the visible numbers is that csview is roughly twice as fast as the next fastest tool and uses the least memory, but the absolute margins on small files are in the millisecond range, which only matters if you are running this in a loop or over a pipe.

Installing on every platform the project lists

csview is packaged for a lot of platforms, and the README documents each route.

On Arch Linux it is in the AUR:

yay -S csview

On macOS it is a Homebrew formula:

brew install csview

On NetBSD it comes from the main pkgsrc repositories:

pkgin install csview

and pkgsrc can also build it from source on any supported platform:

cd /usr/pkgsrc/textproc/csview
make install

On Windows it is a Scoop manifest:

scoop install csview

Pre-built binaries for various architectures are on the GitHub releases page, and there is a note worth heeding: you can try the musl version, which is statically linked, if you run into dependency related errors. That is the usual fix for a static binary that expects a different libc than the one you have.

From source, it is on crates.io and installs with cargo:

cargo install --locked csview

The --locked flag matters, because it makes cargo honour Cargo.lock, and the project ships a Cargo.lock. If you want the latest version rather than the released one, clone the repository and run cargo build --release.

The platform badge covers Linux, OSX, Windows and ARM, and the crate edition is 2024, so the source build needs a recent toolchain.

How the crate is put together

The Cargo.toml is a good short read and shows the design decisions.

The dependency list is deliberately thin. The csv crate at version 1.4 does the parsing, which is the right call rather than hand-rolling a CSV parser. clap 4 with the derive and wrap_help features handles argument parsing, anyhow for error handling, and exitcode so the process can return a meaningful status. Then there are the two that matter for this tool's whole reason to exist: unicode-width, which is the standard crate for measuring a string's display width, and unicode-truncate, which handles truncating a string to a given display width without splitting a wide character in half.

The pager is a Unix-only optional dependency, listed under a target for cfg(target_family = "unix"), and the default feature set is just pager. The pager feature is enabled by default, which means the out-of-the-box behaviour is to page through long output, and building with --no-default-features turns that off for a plain dump.

The release profile sets lto to true and codegen-units to 1, which is the usual pair for a size and speed optimised release build, and the build script uses clap_complete to generate the shell completions that land in the completions/ directory.

There is a build.rs at the root and a rust-toolchain.toml that pins the toolchain, along with rustfmt.toml, a .pre-commit-config.yaml, cliff.toml for changelog generation and release.toml for the release process.

The pager is a feature, and it is the default

It is worth calling out the pager separately, because it changes what the tool is for.

The default feature set in Cargo.toml is pager, and the pager crate is a Unix-only dependency. So the default install of csview is a pager that renders CSV as a table and lets you scroll through it, and on a long file the output does not flood your scrollback.

That is a real difference in approach from the tools it is measured against. xsv table and column both print the entire table to stdout and let the shell handle paging afterwards, which means piping a large file into them gives you a wall of output unless you add less or a pager yourself. csview decides for you.

The tradeoff is that a tool which pages by default is awkward to use in a script that expects the full output on stdout, since a program that waits for a keypress is not a program you want in a pipeline. Building with --no-default-features gives you the plain behaviour, and the pager feature can also be turned off per invocation, though the README does not enumerate that flag set beyond pointing at csview --help.

For an interactive session, which is where most people use a CSV viewer, the default is right.

Licence, releases and the state of the project

The licence is MIT OR Apache-2.0, stated in Cargo.toml as a dual licence, and the repository ships both LICENSE-APACHE and LICENSE-MIT files. Either licence is permissive with no copyleft obligation on a project that consumes the binary, and the choice is yours.

The repository is not archived and the last push was on 2026-10-20. The tagged releases are v1.3.4 from 2024-12-28, v1.3.3 from 2024-07-08 and v1.3.2 from 2024-04-30, and the crate version in Cargo.toml is 1.3.4.

So the published version is about two years behind the last commit, and the commit is recent. That pattern usually means the maintainer is still working but releases only when there is a reason, which is reasonable for a stable tool. It also means that if you are tracking master, you may be running something no one else has run.

Two things the README does not cover. It does not say what the markdown table style looks like in practice, only that it is supported, and it does not describe the full flag set beyond pointing at csview --help, so a user who needs a specific behaviour such as quoting behaviour, header handling beyond -H, or output redirection has to run the help output or read the source.

The documentation is accurate about what the tool does and largely silent about how to drive it, which for a tool this small is a reasonable trade but does mean a short session with csview --help is part of adopting it.

Editorial conclusion

csview is a good fit for anyone who pipes delimited text into a terminal, because the aligned table output is readable and the CJK and emoji width handling removes the ragged column edges that make the classic column tool unusable on non-Latin data. It is a poor fit for a workflow that needs to select, sort or aggregate columns, since it is a viewer and a pager rather than a query tool, and a poor fit if you need to page through a file larger than it holds in memory, given the memory efficiency claim is about the process footprint rather than unbounded streaming. Before adopting, check the flags in csview --help for the delimiter and header handling you need, confirm the pager feature is what you want since it is on by default, and pick the musl build from the release page if your system lacks the expected shared libraries.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. wfxr/csview on GitHub