datavzrd turns tables into interactive HTML reports with vega-lite histograms

A report generator, not a dashboard

datavzrd is described as a tool to create visual and interactive HTML reports from collections of tabular data, with CSV, TSV, JSON and Parquet named as the input formats. The output is a report, and the key detail is what goes into it: reports include automatically generated vega-lite histograms per column.

That single feature is what the tool is for. Given a table of results, you get one distribution plot per column without writing any plotting code, and the result is an HTML document rather than an image or a running service. The README describes the aim as programming- and maintenance-free interactive visualization and communication of tabular data, in the title of the paper the project cites.

The plots are not fixed. They can be fully customized by users via a config file, and the same config file is where you add linkouts to other websites or link between multiple tables, which is what turns a set of plots into a navigable report.

The project is written in Rust, licensed under MIT, and the package metadata gives version 2.75.3, the authors as Johannes Köster and Felix Wiegand, and the edition as 2021. The documentation is at datavzrd.github.io, and the README points at an example report published online together with the corresponding config file in the `.examples/` directory.

The config file is where the report becomes yours

Two things are configurable in this design, and the second is the more interesting one.

The first is the plot itself. The default is an automatically generated vega-lite histogram per column, and users can override that through the config file. The second is navigation. The config file allows the user to add linkouts to other websites, or to link between multiple tables, so a report can point at an external dataset or walk the reader from one table to the next.

The repository ships the example that demonstrates all of this. The README links an online example report and the corresponding config file, which lives in the repository at `.examples/example.datavzrd.yaml`, and the `.examples/` directory is the place to look when you want to see what a working configuration looks like before writing your own.

The configuration format is YAML, and the dependency list shows how the file is handled. `serde_yaml` is present with a comment pointing at a fork of `format_serde_error` to improve error messages, and `schemars` is a dependency too, which is the usual way a Rust project generates a JSON schema for a configuration format. The README does not spell out the schema in full, so the practical starting point is the example file rather than the documentation.

Two directories in the repository explain how the output is produced. `templates/` holds the page templates, and `web/` holds the front-end assets that end up in the report.

A static artefact you can put on any web server

The nature of the output has consequences for deployment, and the dependency list spells them out.

The rendering side is template based. `tera` and `tera-contrib` with the `json` feature are the templating engine and its JSON helpers, `serde_json` handles data, and `slug` and `md5` are present for naming and identifiers. The generated pages are then minified: `minify-html` for the markup and `minify-js` for the scripts, and the latter is pinned to an exact version, `=0.6.0`, with a comment that newer versions generate display issues, referencing pull request 375. A tool that pins a dependency to an exact version because a newer one breaks the rendering is a tool whose output is checked by eye.

`lz-str` is also in the list, which is the usual choice for compressing data that has to be embedded in a page, and `simple_excel_writer` suggests spreadsheet export is part of the flow.

The practical consequence is that what you get is a set of files. There is no server component in the repository, no scheduler and no authentication, so publishing a report means putting the output somewhere a browser can fetch it, which is a much simpler deployment story than running a service. The cost is that the report is fixed at the moment of the run: whatever the data file contained when you ran the tool is what your readers will see.

What the Cargo manifest says about the design

The package manifest is short and informative:

[package]
name = "datavzrd"
description = "A tool to create visual HTML reports from collections of CSV/TSV tables"
license = "MIT"
version = "2.75.3"
authors = [
    "Johannes Köster <[email protected]>",
    "Felix Wiegand <[email protected]>",
]
edition = "2021"

Two dependencies deserve attention because they are not obvious from the feature list.

The first is `readervzrd` at 0.7.0, a separate crate that does the reading of the tabular inputs, so the format handling is factored out of this repository. The second is `pyo3`, version 0.30.1 with the `auto-initialize` and `abi3-py310` features, which is the Rust binding generator for Python. That means the library side of datavzrd can be used from Python, and the manifest declares both a library and a binary:

[features]
default = ["mimalloc"]

[build-dependencies]
fs_extra = "1.3"
ureq = "3"

[profile.release]
codegen-units = 1
lto = "fat"

[lib]
path = "src/lib.rs"

[[bin]]
name = "datavzrd"
path = "src/main.rs"

The `abi3-py310` feature means the extension module targets a stable ABI from Python 3.10 onwards, and the release profile is tuned, with a single codegen unit and fat link time optimisation. The `mimalloc` allocator is behind a default feature, so it can be turned off. The build script pulls in `fs_extra` and `ureq`, and the presence of an HTTP client at build time is worth noting when you consider how the build behaves on a locked down machine.

Built by a research group, published in a journal

The README carries a citation request rather than a feature list, which tells you where this tool comes from.

If you use datavzrd in your research, the README asks you to cite the paper: Wiegand, Lähnemann, Mölder, Uzuner, Prinz, Schramm and Köster, Datavzrd: Rapid programming- and maintenance-free interactive visualization and communication of tabular data, PLOS ONE, 2025, 20(7):e0323079, with the DOI given. A BibTeX entry is included in a collapsed section for convenience, and the repository also carries a `CITATION.cff` file at the top level.

The affiliations are visible too. The badge at the top of the README states an affiliation with RTG 2535 WisPerMed, and the author email addresses are at the domain of TU Dortmund, matching Johannes Köster's own repository.

The distribution is broad for a research tool. There is a Conda recipe on conda-forge with a version badge and a download count badge, so the intended install path for many users is conda rather than a source build, and there is a GitHub Actions workflow for tests on the main branch. The documentation site carries a contributing guide, and the README says contributions of any kind are welcome.

Release cadence is notable. The tags are v2.75.3 from 2026-10-19, v2.75.2 from 2026-10-18 and v2.75.1 from 2026-10-12, so three releases in a week, with the last push on 2026-10-19. The repository is not archived, and the version numbering means that a pin to a minor version is a moving target unless you pin exactly.

Where datavzrd is the wrong choice

The clearest case is live data. datavzrd reads files and writes a report, and the README describes no server, no scheduler and no database connection. If your data changes every minute and the reader needs to see the current state, you are looking at the wrong tool, because the report is only as fresh as the run that produced it.

The second case is access control. A static report that you can put behind a web server inherits that server's authentication, and nothing more. There is no per-report user handling, no tenancy and no audit trail in the feature set, so a report containing sensitive rows is a file you control the exposure of, not a system that controls it.

The third case is input shape. The named formats are CSV, TSV, JSON and Parquet, and the reading is delegated to a separate crate. If your data lives in a database and never touches a file, you have to export it first, and the report then describes a moment rather than a query.

There is also a documentation gap worth naming. The README points at the website for documentation and at the example config for the configuration format, and it does not describe the Python bindings that the `pyo3` dependency implies. If your plan is to drive datavzrd from Python, that is a question for the documentation site rather than for the README.

The alternative: build the report yourself

The alternative approach to publishing tabular results is to construct the report by hand, either with a notebook that emits a page or with a script you write for each dataset. The difference in approach is where the work goes.

In the hand-built route, you own everything. You choose the plots, you write the HTML, you decide what to link to what, and the report matches your intent exactly. The cost is repetition: the next dataset needs the next script, and the tenth dataset needs you to fix the same layout problem again. That is the problem the paper's title is about, programming and maintenance overhead.

datavzrd moves that work into a fixed pipeline. Input files go in, the per-column histograms are generated for you, the templates and assets are applied, the result is minified, and the parts you care about, the plot choices and the links, live in one config file that you can copy to the next dataset.

So the choice is between a report you author once and a report generator you configure repeatedly. If you publish one analysis, a notebook will serve you and will not fight you. If you publish a stream of analyses, the generator is the one that scales, and the price is that the layout is now the tool's opinion with your config file as the override.

Editorial conclusion

Adopt datavzrd when you need to publish tabular results as a shareable interactive HTML report, when the data is a file rather than a live service, and when per-column histograms plus a config file for plot customisation match what you need to publish. Do not adopt it for a dashboard that refreshes, for a database source, or for a report that needs access control, since the output is a static artefact and the README describes no server, no scheduler and no authentication. Verify first that the release you install matches the tag, given that v2.75.3 was published on 2026-10-19 and releases are frequent, that your input files are in a supported format, and that the example config at `.examples/example.datavzrd.yaml` gives you the plot and linkout behaviour you intend to rely on.

Frequently asked questions

Official sources

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