go-cover-treemap turns a Go coverage profile into a picture of where the heat is

Three commands produce one SVG file

The tool is installed with the Go toolchain and then chained with the standard coverage commands, and the whole sequence fits in three lines.

go install github.com/nikolaydubina/go-cover-treemap@latest
go test -coverprofile cover.out ./...
go-cover-treemap -coverprofile cover.out > out.svg

The output is an SVG written to standard output, which means the tool composes with the shell rather than insisting on a file path of its own. The design goal is stated in a single line under the title: it is useful when you have a large project with lots of files and packages. A single percentage tells you that a repository is at 60 percent coverage and nothing else. A treemap draws every directory and file as a box whose area is proportional to size and whose colour encodes heat, so a large red region is visible in a way a number never is. The examples shipped in the repository are real projects, including hugo, gin, chi, treemap itself and go-featureprocessing, and they are rendered at several sizes, 1080 by 360 and 1080 by 180 among them, which tells you the tool is meant for embedding in a document rather than only for a full screen view.

The profile numbers are a lower bound, and the README says so

The disclaimer section is short and it is the most useful thing in the documentation. Every example was produced by running go test -coverprofile <my-file> ./... with no special setup, and some projects require additional steps to run their tests properly and produce a full cover profile. What you see is therefore a lower bound of coverage for those projects. All the profiles were generated on the main branch of each project on 2021-12-07, which is worth knowing before drawing conclusions from the example images, since a repository's test suite and layout change. This is a small tool that is honest about its own limits, and the honesty matters: a coverage visualiser that quietly under-reports is worse than none, and knowing that a red block might be an artefact of how the profile was generated stops you from chasing a phantom.

Statements or files: the sizing choice changes the picture

Appendix A is the part that changes how you read every other image in the repository. When the treemap is sized by statements, the heat of a node is the percentage of covered statements weighted by the sizes of its children. When it is sized by files, the same project produces a different structure, and the argument is that many red file sized boxes become very small and unnoticeable because those files contain non-testable constructs such as constants. The conclusion the author draws is that statements are the more accurate basis for size, since heat is a percentage of covered statements in the first place. In practice this means the default view answers the question you probably have, which is where is the untested code that actually matters, and the file based view is available through a flag for people who think in files. There is also a further variant with statements disabled in the documentation commands, which produces the file sized rendering for comparison.

Root collapsing and folder-only views solve two layout problems

Two layout problems get dedicated treatment in the appendices, and both are about readability rather than data. Appendix B addresses long roots, which occur when the root and its first few children each have only one child. Each such level takes a margin and wastes space, so the tool can collapse them into a longer name and give that space to visualizing deeper levels of the tree. The author notes this is particularly useful in narrow dimensions, which makes a narrow but useful output feasible, and the documentation shows 1080 by 360 and 1080 by 180 renderings with and without root collapsing so the difference is visible. Appendix D addresses projects with lots of files by hiding files and showing only folders, which is also useful when you want to see the impact of the immediate files in a folder on the overall folder heat. The hierarchical properties of size and heat are preserved, and the immediate .go files in a folder are aggregated into a single child, skipped entirely if it is the only one. That suggestion came from a contributor, herlon214.

Accessibility and percentages are first class options

Appendix E treats colour as an accessibility question rather than a cosmetic one. The stated premise is that it is important that everyone can use this tool, and the response is a Red-Blue alternative palette for colour blind readers, suggested by Br3nda, with a before and after rendering of the same project in the repository. Appendix F adds the percentage labels, contributed by artremovechkin, so a box states its number instead of only its colour. Between the two, the tool addresses the two complaints that usually come up with a heatmap: that red and green are unreadable for some viewers, and that a colour scale forces the reader to estimate a value. Appendix C covers the web interface, which is maintained in a dedicated repository, go-cover-treemap-web, and the stated reason for the split is to isolate the web dependencies such as syscall/js from the minimal CLI package. The interactive version lets a browser act as an input source for changing the window dimensions, dragging and dropping a file, and moving a slider to increase the granularity of the treemap.

The dependency surface is two modules and a Go version floor

The go.mod file is a good summary of the project. The module path is github.com/nikolaydubina/go-cover-treemap, the Go version is 1.25.0, and there are two direct dependencies: github.com/nikolaydubina/treemap at v1.2.5, which is the SVG treemap renderer doing the drawing, and golang.org/x/tools at v0.43.0, which provides the official Go parser of the cover profile format. One indirect dependency is listed, github.com/lucasb-eyer/go-colorful, which is the colour library behind the palettes. The reference section in the README points at the official Go tool that makes HTML from a cover profile in the standard library, the golang.org/x/tools cover package that this project reuses, and the author's own treemap renderer. The repository also carries a CITATION.cff file, a SECURITY.md, a docs/ directory holding the example SVGs, a testdata/ directory with the cover profiles used to generate them, and a covertreemap/ package with the library code, plus a web/ directory. The licence is MIT. The most recent release is v1.5.1 from 2026-03-17, and the last push to the master branch was on 2026-08-15.

Editorial conclusion

go-cover-treemap suits teams with a large Go codebase who want to see coverage distribution rather than one number, and it suits anyone who wants a coverage artefact to paste into a review or a dashboard. It does not suit people who need per package percentages for gating, and it does not suit anyone who needs a browser based tool from this repository, since the web UI lives in a separate project. Before adopting it, run go test -coverprofile cover.out ./... on your own repository and read the disclaimer, because the tool reports a lower bound when a project needs extra steps to produce a full profile, and check the flags in the docs section for the sizing and accessibility options you need.

Frequently asked questions

Official sources

1. License: MIT
2. nikolaydubina/go-cover-treemap on GitHub
3. Project website
4. README
5. Releases