fatih/color: ANSI Color Output for Go CLIs, Including Windows

What fatih/color solves for Go command line tools

Printing colored text in Go means embedding ANSI escape sequences in strings. That works until you need to nest a colored value inside a larger format string, reset attributes in the right order, or run the same binary on Windows, where the console historically does not interpret the same escape codes. fatih/color wraps those sequences in a Color type and a set of package-level helpers, so callers write color.Cyan("Prints text in cyan.") instead of assembling the bytes themselves.

The audience is narrow and specific: Go developers building CLI tools, loggers or scripts that print to a terminal. It is not a rendering library. It does not lay out tables, draw progress bars or manage a screen buffer. The README frames it as a way to use colorized output "in terms of ANSI Escape Codes", with the API offered in several styles so you can pick one. If your output target is a web page, a file format or a GUI, this package is the wrong layer.

How the Color type, attributes and writers fit together

The core type is Color, created with color.New, which takes a variadic list of attributes such as color.FgCyan, color.Bold or color.Underline. Attributes can be added later with Add, which is how the README builds variants: a red Color becomes bold red via red.Add(color.Bold). The same object exposes Println, Printf, Fprintln and Fprint, so a single Color can target stdout or any io.Writer you pass in.

For RGB output the package offers color.RGB and color.BgRGB, which construct a Color from 24-bit values. The README notes these require a terminal that supports 24-bit color, and there is no fallback described for terminals that do not. AddRGB and AddBgRGB combine those RGB values with existing attributes.

Three other surfaces exist. PrintFunc, PrintfFunc, PrintlnFunc and their Fprint counterparts return closures that capture a Color, which is useful when you want a named red("Warning") function. SprintFunc and its siblings return strings with the escape codes already embedded, so they can be interpolated into fmt.Printf calls. Finally, color.Set applies attributes globally to subsequent output and color.Unset clears them; the README warns to call Unset, and shows defer color.Unset() as the pattern inside a function.

On the platform side, go.mod lists github.com/mattn/go-colorable, github.com/mattn/go-isatty and golang.org/x/sys as direct dependencies. The repository also contains color_windows.go alongside color.go, matching the README's claim that Windows is supported through go-colorable.

Installing fatih/color and printing your first colored line

The README gives a single install command. Run it inside a Go module so the dependency lands in go.mod.

go get github.com/fatih/color

After that, a minimal program imports the package and calls a helper. The README's first example is color.Cyan, and it notes that a newline is appended automatically.

package main

import "github.com/fatih/color"

func main() {
	color.Cyan("Prints text in cyan.")
	color.Blue("Prints %s in blue.", "text")
}

Running this in a terminal that supports ANSI colors should show one cyan line and one blue line. If you pipe the output to a file or to less, the go-isatty check described in the README disables the color, so the file contains plain text.

For a reusable style, the README shows building a Color and using a closure. This is the pattern to reach for when the same warning style appears in many places.

red := color.New(color.FgRed).PrintfFunc()
red("Warning")
red("Error: %s", err)

If you want colored values inside an existing fmt call rather than whole lines, use the Sprint helpers. The README's example combines them with fmt.Printf and with color.RedString.

fmt.Println("This", color.RedString("warning"), "should be not neglected.")

On Windows, the README says to write to color.Output rather than os.Stdout so that go-colorable handles the translation: fmt.Fprintf(color.Output, "Windows support: %s", color.GreenString("PASS")).

Disabling color: NO_COLOR, non-tty streams and the NoColor flag

Color suppression is where this package has the most documented behavior, and it is worth reading before you add a flag of your own. Two automatic mechanisms are described. The go-isatty package disables color when the output stream is not a tty, for example when output is piped to less. Separately, the color package disables output when the NO_COLOR environment variable is set to a non-empty string, following the convention at no-color.org.

Programmatic control has two levels. The package-level variable color.NoColor turns color off globally, and the README pairs it with a typical flag declaration:

var flagNoColor = flag.Bool("no-color", false, "Disable color output")

if *flagNoColor {
	color.NoColor = true // disables colorized output
}

A single Color can also be toggled at runtime with DisableColor and EnableColor, which the README demonstrates by printing cyan, disabling, printing plain, then re-enabling.

The CI case is the one that trips people up. Because non-tty output disables color automatically, a GitHub Actions log will not show ANSI codes unless you override the check. The README states this directly: set color.NoColor = false to bypass the non-tty detection in CI systems that do support ANSI colors. Note the interaction: if a CI environment also sets NO_COLOR, the two mechanisms are independent, and the README does not document which one wins.

Where fatih/color stops: no layout, no 24-bit fallback, no rollback

The package colors strings and writes them. Anything beyond that is your problem. There is no table renderer, no column alignment, no progress bar and no input handling, so a tool that needs those has to bring another library and use fatih/color only for the text inside it.

The RGB functions assume a terminal that supports 24-bit color. The README says so and offers no degradation path, so on a terminal limited to 16 colors the escape sequences for color.RGB and color.BgRGB may render incorrectly or not at all. If you target a wide range of terminals and cannot detect their capability yourself, the named attributes (FgRed, BgWhite and so on) are the safer choice.

Global state is the other sharp edge. color.Set changes attributes for all subsequent output in the process, and the README tells you to call color.Unset, showing defer color.Unset() inside a function. Forget it and the styling leaks into unrelated output. The package-level color.NoColor variable is similarly process-wide, so a library that flips it affects its host program. Libraries should prefer per-instance Color objects with DisableColor rather than mutating the global.

Finally, the README does not document rollback, version pinning policy or a compatibility guarantee across releases. The repository has no CHANGELOG in its top-level entries; the release history is visible only through tags such as v1.19.0, v1.18.0 and v1.17.0. The last push to the repository was on 2026-09-09.

fatih/color compared with writing escape codes yourself

The obvious alternative is not another library but no library: define your own constants for the escape sequences and print them directly. That approach has real advantages. You control exactly which codes are emitted, you can implement your own tty and NO_COLOR checks, and you add zero dependencies to go.mod. It also removes the global color.NoColor variable from your process.

The difference in approach is that fatih/color centralizes three things you would otherwise reimplement: attribute composition (Add, AddRGB), writer targeting (the Fprint family and color.Output), and platform translation through go-colorable on Windows. Writing escape codes by hand means the Windows path is yours to solve, and the README's own credit section attributes Windows support to go-colorable, which is a dependency you would be pulling in anyway or replacing. If your tool prints a handful of colored lines on Linux only, hand-rolled constants are a defensible choice. If you ship on Windows, support RGB, or want the closure helpers, the package earns its place in go.mod.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-09-09. Releases are infrequent: v1.17.0 in May 2024, v1.18.0 in October 2024 and v1.19.0 in March 2026. That cadence matters less than it looks, because the API surface is small and the underlying mechanism, ANSI escape codes, is stable. The go.mod declares go 1.25.0, so older toolchains need to check compatibility before upgrading.

Upgrade cost is mostly the dependency graph. Direct requirements are github.com/mattn/go-colorable v0.1.15, github.com/mattn/go-isatty v0.0.23 and golang.org/x/sys v0.47.0. A bump in golang.org/x/sys or go-isatty can change tty detection behavior, which is exactly the code path that decides whether your output is colored, so a dependency update is worth a manual check of piped output rather than a blind go get -u.

The licence is MIT, stated in the README and present as LICENSE.md at the repository root. MIT is permissive and imposes no copyleft on your program. That is a factual note, not legal advice; if your organization has licence review requirements, run the LICENSE.md text through it.

Editorial conclusion

Adopt fatih/color if you are writing a Go CLI or tool that prints to a terminal and you want colored output without hand-writing escape codes, especially if you ship on Windows. Do not adopt it if you need styled text layout, tables, progress bars or a full TUI; it only colors strings and writes them to a writer. Before adding it, verify three things: that your terminal or CI sets TERM appropriately, that your CI job sets color.NoColor = false if you want ANSI in logs, and that your own -no-color flag maps to color.NoColor as the README shows. The package is small, MIT licensed, and its only direct dependencies are go-colorable, go-isatty and golang.org/x/sys.

Frequently asked questions

Official sources

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