jedib0t/go-pretty: Go Tables, Lists and Progress Bars for Terminal Output

What go-pretty is for and who reaches for it

A Go program that prints a slice of structs to stdout gets whatever fmt.Println produces: values separated by spaces, no column widths, no wrapping, no alignment. go-pretty exists to fix that. The README describes it as "Utilities to prettify console output of tables, lists, progress bars, text, and more with a heavy emphasis on customization and flexibility." The audience is Go developers writing command line tools, test helpers, and batch jobs whose output a human reads in a terminal, or whose output a machine reads as CSV, TSV, Markdown or HTML. The table package is the centre of gravity: it supports colors, auto-merge, sorting and paging, and it renders to ASCII, HTML, Markdown, CSV and TSV from the same data. The list package handles hierarchical output with multiple levels and indentation. The progress package tracks one or more tasks with ETA, speed calculation and indeterminate indicators. The text package is the shared utility layer for alignment, colors, cursor control, case conversion, JSON and time formatting, padding, trimming and wrapping, and it carries full ANSI escape sequence support. That layering matters: text is used extensively by the other packages, so its behaviour around ANSI sequences is what makes colored cells line up in a table.

How the packages fit together

The repository is a single Go module, github.com/jedib0t/go-pretty/v6, split into four importable packages plus a cmd directory of demos. The module declares go 1.18, so the language floor is Go 1.18. Dependencies are small and mostly about terminal text: github.com/mattn/go-runewidth and github.com/rivo/uniseg handle character width and grapheme clustering, golang.org/x/term and golang.org/x/sys handle terminal detection and control, golang.org/x/text provides text primitives, and github.com/pkg/profile, stretchr/testify, felixge/fgprof and google/pprof appear for profiling and tests. The data flow is the same in each package: you build an in-memory representation, configure styles and column behaviour, then ask for a rendering in a chosen format. The table package is the clearest example, because the same table can be written as ASCII for a terminal, Markdown for a pull request comment, or CSV for a downstream script. That is the main architectural bet, and it is a reasonable one. The cost is that the rendering step is where nearly all the complexity lives, and the top-level README does not document the writer interface, so table/README.md is where the real API surface is described. The repository ships a Makefile with test, lint, vet, cyclo, bench and test-race targets, and a cmd directory with demo-table, demo-list and demo-progress programs, which is how the maintainer documents behaviour that prose would be tedious to describe.

Installing go-pretty and rendering a first table

Installation is a single go get against the v6 module path. The README gives exactly this command, and the /v6 suffix is required because the current major version is v6.

go get github.com/jedib0t/go-pretty/v6

After that, import only the packages you need. The README shows this import block, and each subpackage has its own path under the module.

import (
    "github.com/jedib0t/go-pretty/v6/table"
    "github.com/jedib0t/go-pretty/v6/list"
    "github.com/jedib0t/go-pretty/v6/progress"
    "github.com/jedib0t/go-pretty/v6/text"
)

The README's own table sample renders a header row, three data rows and a total row, with the salary column right-aligned and the last column holding free text. The rendered shape is what you should expect to see in your terminal:

+-----+------------+-----------+--------+-----------------------------+
|   # | FIRST NAME | LAST NAME | SALARY |                             |
+-----+------------+-----------+--------+-----------------------------+
|   1 | Arya       | Stark     |   3000 |                             |
|  20 | Jon        | Snow      |   2000 | You know nothing, Jon Snow! |
| 300 | Tyrion     | Lannister |   5000 |                             |
+-----+------------+-----------+--------+-----------------------------+
|     |            | TOTAL     |  10000 |                             |
+-----+------------+-----------+--------+-----------------------------+

Before writing your own table, the README points at a runnable demo that needs no clone. This runs the nested colored tables example straight from the module, which is the fastest way to see how colors behave inside cells:

go run github.com/jedib0t/go-pretty/v6/cmd/demo-table@latest colors

The README shows the output as a screenshot, so the exact escape sequences are not reproducible here. If you want the same for lists or progress bars, the cmd directory contains demo-list and demo-progress, and the Makefile has demo-list, demo-progress, demo-table and demo-colors targets for running them from a checkout.

Where go-pretty stops being the right tool

go-pretty formats output. It does not own the terminal. The README describes progress tracking and cursor control through the text package, but it does not describe an event loop, key handling, focus management or a widget tree, and there is no mention of alternate screen buffers or mouse input. If your program needs a full-screen application where the user moves between panes or types into fields, go-pretty is the wrong layer, and reaching for it will leave you implementing the missing half yourself. The progress package is the closest thing to live output, and its README is a separate file that the top-level README only links to, so the details of update rates, channel handling and finish behaviour are not visible from the entry point. There is a second, quieter constraint: the module path is versioned at v6, and the README states plainly that the current major version is v6, pointing at the Go modules versioning rules. Any code you find online that imports github.com/jedib0t/go-pretty/table without the /v6 segment targets an older major version and will not resolve against the current release line. The repository does not document a migration guide from v5 to v6, so a major-version upgrade means reading the release notes and the per-package READMEs yourself. Finally, the top-level README is largely a pointer document. It shows one table, one list, and screenshots for progress and colors, then defers to table/README.md, list/README.md, progress/README.md and text/README.md. That is fine for a library with four distinct packages, but it means the entry point alone is not enough to judge the API.

go-pretty against text/tabwriter and the tablewriter family

The obvious comparison is text/tabwriter in the Go standard library, which is what people search for as "Golang tabwriter". tabwriter aligns columns using tab-terminated cells and elastic tabstops. It has no notion of a header row, no borders, no colors, no sorting, no paging, and no alternative output formats. It is a filter over an io.Writer, and it is excellent at that one job. go-pretty instead models a table as an object with a header, rows and footers, then renders it. That difference is why go-pretty can emit Markdown or CSV from the same data while tabwriter cannot: tabwriter only knows about padding. The trade is dependency count and API surface. tabwriter is stdlib and zero-config; go-pretty pulls in runewidth, uniseg, x/term, x/sys and x/text, and asks you to learn its writer configuration. If all you need is aligned columns of plain text with no borders, tabwriter is smaller and has no versioning decisions to make. The other comparison people search for is "Golang tablewriter", which usually means the separate github.com/olekukonko/tablewriter project. Both render bordered ASCII tables from Go slices. Its own documentation is not part of this review, so the honest difference to state is scope: go-pretty ships list, progress and text packages alongside the table package, and its README advertises multiple output formats including HTML, Markdown, CSV and TSV. If you only need a bordered table and nothing else, the extra packages are weight you will not import.

Maintenance, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-09-18. The most recent tagged release listed is v6.8.3 on 2026-07-19, preceded by v6.8.2 on 2026-06-30 and v6.8.1 on 2026-06-11. That is a steady patch cadence across the summer of 2026, and the release numbering stays inside the v6 major line, which means upgrades between these tags are minor-version changes rather than breaking module path changes. The licence is MIT, which is permissive and short; the repository carries a LICENSE file at the top level. For a library you vendor or import into a commercial Go binary, MIT imposes essentially the attribution obligation and nothing more, but read the file yourself rather than treating that as advice. Upgrade cost is the part worth thinking about before you adopt. Because the module path is pinned at /v6, a future v7 would be a new import path and a mechanical but repo-wide edit of import statements. Within v6, the Makefile shows the maintainer's own quality gates: go vet, golangci-lint, gocyclo with a warning threshold above 13, gofmt plus gosimports, and a race-detector target that runs the test suite and the progress demo. Those targets describe the maintainer's workflow, not a guarantee about your code, but they do indicate that formatting, static analysis and race testing are part of the release process rather than an afterthought.

Editorial conclusion

Adopt go-pretty when a Go program already prints structured data to a terminal or a log and you want table borders, column alignment, or a progress bar without writing escape sequences by hand. Do not adopt it if you need an interactive full-screen TUI with key handling and widgets; that is a different class of library. Before committing, read table/README.md and progress/README.md in full, because the top-level README only points at them, and check that your module path carries the /v6 suffix, since the current major version is v6 and the import paths in the README all include it.

Frequently asked questions

Official sources

1. Issues
2. jedib0t/go-pretty on GitHub
3. License: MIT
4. README
5. Releases