doxx: reading .docx files in the terminal, and where it stops

The gap doxx fills: .docx files on machines without Word

Word documents arrive as email attachments, Jira tickets and shared drives. On a Linux server or a minimal developer workstation, opening one usually means a round trip through a web converter, a LibreOffice install, or a colleague with a desktop licence. doxx targets exactly that gap. The README describes it as a "terminal-native document viewer for Word files" that lets you "view, search, and export `.docx` documents without leaving your command line."

The audience is narrow but real: backend engineers inspecting generated reports on a build host, sysadmins reading a policy document on a headless box, anyone who wants a .docx's tables as CSV in a shell pipeline. It is not for people who need to write prose in Word format. The feature list contains view, search, copy, export and navigation. Editing does not appear.

How doxx reads a .docx: unzip, parse, render with ratatui

A .docx is a ZIP archive of XML parts. The dependency list in Cargo.toml shows the chain doxx uses: the `zip` crate to open the container, `docx-rs` to parse the document model, and `quick-xml` alongside it for XML handling. Formatting decisions then pass through `ratatui` and `crossterm` for the interactive terminal UI, with `unicode-segmentation` and `unicode-width` handling grapheme clusters and column widths so tables line up in a monospace grid.

Images take a separate path. `ratatui-image` and `viuer` are both dependencies, and the README lists terminal images for Kitty, iTerm2 and WezTerm. That is a capability-detection problem as much as a rendering one: not every terminal speaks those protocols, and the README's own example guards the feature behind an explicit flag. Export is the other output mode, and it bypasses the TUI entirely. The README's option table lists `markdown`, `text`, `csv`, `json` and `ansi` as export formats, which means the same parsed document can be dumped to stdout for a pipe instead of drawn to a screen. `arboard` is present for the clipboard feature, and `dirs` plus `toml` suggest a configuration file under the user's config directory, though the README does not document its keys.

Installing doxx and running a first export

The README offers package managers for most platforms. On macOS or Linux with Homebrew, the tap is the shortest route:

brew install bgreenwell/tap/doxx

Cargo works anywhere a Rust toolchain exists, and Cargo.toml sets the crate's `rust-version` to 1.88, so an older toolchain will refuse the build:

cargo install doxx
doxx --version

The version output confirms which release you installed. Debian and Ubuntu users get a distro package named `rust-doxx`, available in testing (forky):

sudo apt install doxx

Arch, Nix, NetBSD and Conda-Forge each have their own command in the README, and prebuilt binaries are published for `x86_64-unknown-linux-musl`, both macOS architectures and `x86_64-pc-windows-msvc`.

For a first real use, pick a document with a table in it. Viewing is the default:

doxx report.docx

That opens the interactive UI. To skip the UI and pipe structured output, use an export. The README is explicit that CSV covers tables only:

doxx data.docx --export csv > data.csv
doxx report.docx --export markdown > report.md

Search accepts a term at launch, which is useful when you know what you are looking for and do not want to scroll:

doxx contract.docx --search "payment"

The match is highlighted in the viewer. If your terminal supports images and the document embeds them, the README's example adds the flag:

doxx presentation.docx --images --export text

Where doxx is the wrong tool

The most important limitation is in the README's own framing: doxx views. There is no edit command, no tracked-changes view and no comment handling in the documented option set. If a contract arrives with revisions to accept, doxx shows you the text and nothing else. That is a deliberate scope choice, and it means the tool cannot replace Word or LibreOffice for review work.

Export fidelity is the second constraint. The README warns in a parenthetical that `--export csv` extracts tables only, so a document that mixes narrative and tables will lose the narrative in CSV mode. Markdown export is a conversion, and conversions of complex Word layouts have edges; the README does not publish a fidelity table, so anyone depending on exact output should diff a few real documents before trusting it in a pipeline.

Platform packaging has gaps too. The Scoop section for Windows is marked "Coming soon" in the README, so Windows users are pointed at the prebuilt `x86_64-pc-windows-msvc` binary or Cargo rather than a package manager. And the README does not document rollback, uninstall steps or a configuration file schema, even though `dirs` and `toml` are dependencies.

doxx compared with docx2txt and LibreOffice headless

The obvious alternative in the same niche is docx2txt, which appears in the related searches for this project. The difference is architectural. docx2txt is a converter: you run it, it emits text, and it exits. doxx keeps a TUI, so the same binary supports interactive navigation with an outline view (`--outline`), a page jump (`--page`), saved scroll positions (`--restore-position`) and in-document search highlighting. If your only need is a text dump in a script, docx2txt's single-purpose shape is simpler. If a human is going to read the document, the navigation is the point.

The other alternative is `libreoffice --headless --convert-to`, which uses a full office engine. That path handles far more of the format, but it drags in a large dependency and is slower to start. doxx's dependency list is a Rust crate set, and the Linux release artifact is statically linked against musl, so it drops onto a machine with no office stack at all. The trade is coverage: LibreOffice understands document features doxx's parser may not.

None of these tools edit. If editing is the requirement, none of the three is the answer.

Licence, releases and the cost of keeping up

doxx is MIT licensed, both in the Cargo.toml `license` field and the README badge. MIT is permissive: you can bundle the binary in internal tooling, and the only real obligation is preserving the copyright notice and licence text. That is a description of the licence terms, not legal advice; check with your own counsel if you redistribute it commercially.

The release history is short. v0.1.4 is the most recent release, dated 2026-05-26, following v0.1.2 in 2025-10-21 and v0.1.1 in 2025-08-22. The repository is not archived, and the last push was on 2026-08-10, so the project is still receiving changes. The version number still sits in 0.1.x, which is worth weighing: pre-1.0 CLIs can change flags between releases, and the README's option table is the contract you would be coding against.

Upgrade cost is low if you use a package manager, since `brew`, `apt`, `pacman` and `conda` all pull new versions for you. It is higher if you pinned a prebuilt binary in a Docker image or a CI cache, because you would be tracking the GitHub releases page by hand. The repository carries a CHANGELOG.md and a RELEASE_CHECKLIST.md, so release notes exist to read before bumping.

Editorial conclusion

Adopt doxx if you read .docx files on Linux, macOS or Windows boxes where Word is not installed, and especially if you need scriptable exports such as `doxx data.docx --export csv`. Do not adopt it if your workflow requires editing, tracked changes or comment review, because the README describes only viewing, searching and exporting. Before rolling it out, check the release page for your platform's prebuilt binary and confirm your terminal handles the image and color paths.

Frequently asked questions

Official sources

1. bgreenwell/doxx on GitHub
2. License: MIT
3. Project website
4. README
5. Releases