WhiteboxTools is a legacy Rust geospatial backend, superseded by Whitebox Workflows Next Gen

The legacy notice comes before everything else in the README

The first line of the README is a notice, and it changes how everything else should be read. It says this repository is marked as legacy, that Whitebox development has moved on to Whitebox Workflows Next Gen, and that all issues and concerns should be reported there.

That is a materially different situation from a project that is merely quiet. A quiet project may still be the right tool. A legacy project is one whose author has redirected the work, and the practical effect is that any effort you invest in this repository, in bug reports, in extensions, in documentation, is effort that will not be carried forward.

The code itself is not a toy. WhiteboxTools is described as an advanced geospatial data analysis platform developed by Prof. John Lindsay at the University of Guelph's Geomorphometry and Hydrogeomatics Research Group, and the repository is MIT licensed with the last push on 2026-05-26. The release history shows v2.4.0 in May 2024, v2.3.0 in March 2023 and v2.2.0 in October 2022, so the tagged artefacts are older than the recent commits.

The homepage is whiteboxgeo.com, the project describes itself as an advanced geospatial data analysis platform, and the compiled binaries for Windows, macOS and Linux are distributed from the company website rather than from GitHub releases.

The tool covers four domains, and the hydrology work is the deepest

The description of what the platform does is long, and reading it tells you what the project is actually for.

The common GIS operations are cost-distance analysis, distance buffering and raster reclassification. Remote sensing and image processing covers image enhancement such as panchromatic sharpening and contrast adjustments, image mosaicing, numerous filtering operations, classification and common image transformations.

The advanced terrain and hydrology tooling is the part that distinguishes WhiteboxTools from a general GIS. Spatial hydrological analysis includes flow-accumulation, watershed delineation, stream network analysis and sink removal. Terrain analysis includes the common indices such as slope, curvatures, wetness index and hillshading, plus hypsometric analysis and multi-scale topographic position analysis.

The LiDAR support is the deepest area. Point clouds can be interrogated with LidarInfo and LidarHistogram, segmented, tiled and joined, analysed for outliers, interpolated to rasters such as DEMs and intensity images, and ground points can be classified or filtered.

The topics list on the repository matches this: geomorphology, geomorphometry, geoprocessing, geospatial, gis, hydrology and remote-sensing. This is a landscape analysis toolkit rather than a mapping one, and the last sentence of the description makes that explicit. WhiteboxTools is not a cartographic or spatial data visualization package, and is instead meant to serve as an analytical backend for other data visualization software, mainly GIS.

That positioning has consequences for how you use it. It is a set of computations, not a workspace, and there is no map to draw results in.

One binary, no installation, and a Python interface on top

The distribution model is unusually frictionless for a geospatial tool. WhiteboxTools is a stand-alone executable command-line program with no actual installation, and pre-compiled binaries are downloaded from the Whitebox Geospatial website with support for various operating systems.

There is no installer, no package manager entry, no system service. You download the binary and run it. The Python programming interface is the second surface, and it needs Python 3 or higher installed.

The repository layout shows how the two fit together. whitebox_tools.py is the Python interface, and wb_runner.py is a separate script. The Rust side is a Cargo workspace with members whitebox-common, whitebox-lidar, whitebox-plugins, whitebox-raster, whitebox-runner, whitebox-tools-app and whitebox-vector, and there are per-plugin directories for the tool implementations.

The workspace profile is set for shipping binaries rather than for debugging them, with incremental set to true and strip set to true in the release profile. The size of the release profile is not a detail worth much attention, but the strip setting is the one that matters operationally: the built executables are stripped, which is what you want in a tool you ship to other machines.

There is also a whitebox_plugin_generator.py, which suggests that adding a new tool to the platform is a supported activity rather than something you would have to reverse-engineer. A tool_porting.md file and a settings.json and versioning_info.json sit at the root as well.

Building from source needs Rust, a Python build script and a linker

The build path is documented in four steps after installing the Rust compiler, with Rustup recommended.

You download the repository, decompress the archive, change into the whitebox-tools folder, and run the build script:

>> cd /path/to/folder/whitebox-tools/

>> python build.py

The README notes that on some systems you may need to use the python3 command instead, and that the compilation may take several minutes depending on your system.

The build.py script is the interesting part, because the README says to read its notes for how to customise the build. Three arguments are called out: do_clean, exclude_runner and zip, which can be used to add or remove functionality during the build process. exclude_runner in particular is how you drop the GUI runner from a headless build, and the build script requires a Python environment even though WhiteboxTools itself is pure Rust code.

When the build completes, it creates a new WBT folder inside whitebox-tools containing everything needed to run the program: the main Whitebox executable file, the Whitebox Runner GUI application, and the various plugins.

The Windows note is the one that trips people up. If you are installing on MS Windows you must have a linker installed prior to installing the Rust compiler, and the Rust webpage recommends either the MS Visual C++ 2015 Build Tools or the GNU equivalent. Rustup is the recommended way to install the compiler.

The reason to build from source at all is stated plainly: it is likely that WhiteboxTools will work on a wider variety of operating systems and architectures than the distributed binary files, so if your platform is not in the list of available binaries, compilation is necessary.

The binary is the product, and the binary is not on GitHub

There is a distribution detail that catches people out. The README points to the Whitebox Geospatial website for compiled binaries for Windows, macOS and Linux, and the repository's own top-level entries include a.DS_Store file and a.vscode directory, which tells you the repository is the source of truth for code rather than for artefacts.

The website, whiteboxgeo.com, is the distribution point and also the documentation point. The official User Manual is at the whiteboxgeo.com manual link, and the README refers readers there for help, noting that WhiteboxTools possesses extensive help documentation. There is also a UserManual.txt at the repository root and a readme.txt.

The split matters for two reasons. First, if you are building a reproducible pipeline, the version you get is whatever the website currently serves. The tagged versions here are v2.4.0 from 2024-05-22 and v2.3.0 from 2023-03-28, and the source has moved on since, so the website binary and a checkout of master are not the same thing.

Second, this is a company site rather than a package registry, so there is no dependency resolution, no lockfile, no transitive version conflicts. For a binary tool that runs standalone, that is often a feature, and for a library you want to depend on, it is a problem. This is a program, not a library, and the Python interface is a wrapper around the program rather than a Rust crate you would put in a Cargo.toml.

Where WhiteboxTools is the wrong choice

The first wrong-tool case is the simplest one. If you are starting a new geospatial project in 2026, the README tells you not to start here, because development has moved to Whitebox Workflows Next Gen. Adopting a legacy repository when its successor is public and named in the first paragraph of the README is a choice you would have to justify.

The second is visualization. The tool is explicitly not a cartographic or spatial data visualization package. If you need to look at results, map them, or produce a figure, you need other software, and WhiteboxTools is the thing feeding it. That is a perfectly good design, but it means there is no standalone path from data to a map here.

The third is the tool category. The tool set is landscape analysis: hydrology, terrain, LiDAR, remote sensing. Cost-distance, buffering and reclassification are there, but this is not a general-purpose vector GIS with editing, geodatabase support and a topology engine. If your work is about manipulating and editing vector features rather than analysing terrain, this is the wrong category of software.

The fourth is the dependency story for the Python interface. The Python interface drives an external binary. That means the binary has to be present and locatable on the machine running the script, which turns a simple pip install into a deployment problem with a second artefact to version and distribute. In a container image or a batch job, that is a real cost, and it is the cost of the no-installation distribution model working in reverse.

The MIT licence is worth noting as a positive. It is permissive, with no copyleft obligation for a commercial or institutional use of the platform, and the licence text is in LICENSE.txt at the repository root.

Editorial conclusion

WhiteboxTools fits an existing geospatial pipeline that already calls the classic WhiteboxTools command-line program or its Python interface and needs to keep working, and it does not fit a new project, because the repository is marked legacy and all issues and concerns are directed to Whitebox Workflows Next Gen. Before adopting anything here, read the legacy notice at the top of the README, check whether the tool you actually need lives in the successor, and note that the last tagged release is v2.4.0 from 2024-05-22 while the last push was on 2026-05-26.

Frequently asked questions

Official sources

1. jblindsay/whitebox-tools on GitHub
2. License: MIT
3. Project website
4. README
5. Releases