QuPath: open source bioimage analysis for whole slide and microscopy images

What problem QuPath solves, and for whom

Whole slide images are large, vendor-specific and awkward to quantify. A pathologist or biologist who wants a cell count, a positive-pixel area or a tissue microarray readout usually ends up either in a general image editor that has no concept of a slide, or in a script that has no viewer. QuPath sits between those. The README describes it as open source software for bioimage analysis, with tools to annotate and view whole slide and microscopy images, workflows for brightfield and fluorescence analysis, and algorithms for cell segmentation and tissue microarray dearraying.

The audience is explicit. QuPath is an academic project, and the README states it is intended for research use only. It is developed at the University of Edinburgh, with funding listed from the Wellcome Trust and the Chan Zuckerberg Initiative. If your work is a published study that needs an open, inspectable analysis method, that framing fits. If your work is a clinical diagnosis, the project itself does not claim to support you.

The scope is wider than cell counting. Interactive machine learning for object and pixel classification, batch processing, and scripting for data interrogation are all listed features, and the repository carries extensions for Bio-Formats, OpenSlide, SVG export and a script editor. QuPath is closer to a small analysis platform than to a single-purpose tool.

How the application is put together

The repository layout tells you the architecture before you read any documentation. There is qupath-core, qupath-core-processing and qupath-gui-fx: a core library, a processing layer, and a JavaFX desktop interface. Everything else is an extension. Image reading is not baked into the core in one monolithic way; qupath-extension-openslide and qupath-extension-bioformats are separate modules, which is why the set of slide formats you can open depends on which extensions are present. qupath-extension-processing, qupath-extension-script-editor and qupath-extension-svg cover analysis, scripting and vector export respectively.

That split has a practical consequence. The application is a desktop program, not a service. There is no server process, no HTTP API and no container in the top-level layout; a jpackage directory exists for packaging installers. Work happens in a locally opened project, and the scripting layer (Groovy is listed among the repository topics) is how you automate it. Batch processing in QuPath means running a script across images in a project, not calling a remote endpoint.

The README also points to ImageJ integration as a feature. That matters for anyone with an existing ImageJ pipeline: QuPath is not asking you to abandon it, but it is also not a drop-in replacement for it.

Installing QuPath and running a first cell detection

The README does not give command-line installation steps. It says, in one line, that to download QuPath you go to the Latest Releases page on GitHub. So the install is a download and run, not a package manager invocation, and the same route covers Windows, macOS and Linux. The current release listed is v0.7.0.

Once it is open, the first real task is usually cell detection on an annotated region. The README lists cell segmentation among the new algorithms for common tasks, and the workflow is annotation first, detection second: you draw a region with the annotation tools, then run detection on it. The README does not print a script for this, and it does not document the detection parameters, so the parameter values come from the dialog in the application rather than from the documentation. What the README does establish is that scripting is the route to batch processing and data interrogation, and that Groovy is the scripting language the repository is tagged with.

After detection runs, the cells appear as objects over the image and can be measured. The second task most people reach for is classification. QuPath offers interactive machine learning for object and pixel classification. You train a pixel classifier by drawing example regions, then apply it to the image to produce a classification that can be converted into objects. Object classification works the other way: you label existing detections and train a classifier on their measurements. Both are interactive, meaning you supply the training data by annotating, and the project does not ship a pretrained model for your tissue.

Where QuPath stops being the right tool

The strongest limitation is stated by the project itself: research use only. That is not a disclaimer buried in a licence file, it is in the README next to the GPLv3 sentence. Anyone looking for a diagnostic or regulated workflow is not the intended user, and the software makes no claim to be one.

The second limitation is architectural. QuPath is a desktop application with a graphical interface at its centre. If your requirement is a headless pipeline that ingests slides and emits results on a schedule, QuPath gives you scripting and batch processing, but the model is still a local project and a locally installed application, not a service you deploy. Teams that need an API-first workflow will find themselves wrapping a desktop tool rather than calling one.

The third is format coverage. Because OpenSlide and Bio-Formats support live in separate extension modules, opening an unusual vendor format is not guaranteed by the core application. The README does not document a fallback for unsupported formats, and it does not document rollback or migration between project versions either. If you build a long-running study on a QuPath project, the upgrade path between releases is something you would need to check against the CHANGELOG rather than assume.

QuPath compared with ImageJ and Fiji

ImageJ, and its bundled distribution Fiji, is the obvious alternative, and QuPath's README treats it as a partner rather than a rival: easy integration with other tools including ImageJ is listed as a feature.

The difference in approach is what each tool assumes you are doing. ImageJ is a general image processing application with a plugin ecosystem; it handles a stack of images well and has no built-in notion of a slide, an annotation hierarchy or a project of many slides. QuPath is built around the slide and the project. Annotations are first-class objects, classifications are attached to objects, and measurements accumulate on them. If your work is a handful of images and a custom processing chain, ImageJ is the lighter choice. If your work is hundreds of slides where you need to annotate, train a classifier and then export per-object measurements, QuPath's data model is doing work that ImageJ would leave to you to build.

Maintenance, upgrades and the GPLv3 licence

The repository is not archived, and the last push was on 2026-09-08. Releases are not frequent: v0.7.0 landed on 2026-03-02, after a release candidate on 2026-02-17, and v0.6.0 before that on 2025-06-27. That cadence is normal for a research tool with a small team, and the README names three current developers at the University of Edinburgh plus past team members. Funding is listed from the Wellcome Trust and CZI, which is the honest signal of how the project is sustained.

The upgrade cost is real but bounded. Because the application is distributed as a downloadable release rather than through a package manager, upgrading means downloading a new version and opening your existing project with it. The repository carries a CHANGELOG.md, so version-to-version changes are documented there, and a VERSION file tracks the current version. The README does not promise that projects are forward or backward compatible, so treat a version jump as something to test on a copy of a project rather than on your only copy.

On licensing: QuPath is GPLv3. For a researcher running analyses locally, that is unremarkable. For anyone who wants to redistribute QuPath inside a product, or link it into proprietary code, the copyleft terms are the thing to read before you build. This is a description of the licence, not legal advice, and the repository also contains an unknown-license-details.txt file, which suggests the maintainers have looked at dependency licensing themselves.

Editorial conclusion

Adopt QuPath if you are a researcher who needs to annotate, segment and quantify whole slide or microscopy images and you are willing to learn its annotation and classifier workflow, or to script it in Groovy. Do not adopt it for clinical or diagnostic use: the README states plainly that it is an academic project intended for research use only, and it is GPLv3, so check how that interacts with your own distribution plans before you build on it. Before committing, verify one thing in practice: install the current v0.7.0 release on your own operating system and open one of your own slide formats, since the extensions that read vendor formats are separate modules (qupath-extension-openslide, qupath-extension-bioformats) and your file may not open without them.

Frequently asked questions

Official sources

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