gookit/color keeps one Print API across three colour depths and Windows

One Print family covers all three colour depths

The API surface is the argument. The README lists generic methods `Print`, `Printf`, `Println`, `Sprint` and `Sprintf`, and those same five work whether you are printing 16-colour, 256-colour or true colour. Depth is a property of the colour value you hold, not of the call you make.

The quick start shows all three styles side by side. Package-level helpers like `color.Redp` and `color.Cyanln` print straight away. Colours as values work like a `fmt` receiver, so `color.Cyan.Printf("Simple to use %s\n", "color")` reads like the standard library. And a colour can be held as a function, since `color.FgRed.Render` is passed to `fmt.Printf` when you want to compose escape codes yourself.

// quick use package func
color.Redp("Simple to use color")
color.Cyanln("Simple to use color")

// quick use like fmt.Print*
color.Cyan.Printf("Simple to use %s\n", "color")

// use like func
red := color.FgRed.Render
green := color.FgGreen.Render
fmt.Printf("%s line %s library\n", red("Command"), green("color"))

That last form is the escape hatch. When you want the escape sequence as a value, say in a log line built elsewhere, `Render` gives you the string without printing it.

Install is a single `go get` with no dependencies of its own, and the module requires only `gookit/assert` for tests, `xo/terminfo` and `golang.org/x/sys`.

True colour on CMD and PowerShell only arrived in v1.2.4

The Windows story is the reason this library exists, and it is versioned rather than assumed. The feature list says that 16-colour output "is the most commonly used and most widely supported, working on any Windows version", while since `v1.2.4` the 256-colour and true colour support Windows CMD and PowerShell.

The repository reflects that split in its file names: `color_16.go`, `color_256.go`, `color_rgb.go` and `color_tag.go` sit next to `detect_env.go`, `detect_nonwin.go` and `detect_windows.go`. The two detect files are the mechanism, one implementation for Windows and one for everything else, which is why 16-colour works everywhere while the deeper modes needed a Windows-specific path.

If you are supporting an old version of this library, that boundary is the thing to check: before v1.2.4 the extra depths on Windows terminals were not available.

The RGB and 256 APIs are explicit about how you ask for a colour. `color.C256(val uint8, isBg ...bool)` returns a 256-colour value, so `color.C256(132)` is a foreground and `color.C256(132, true)` is the same value as a background. The variadic flag is how the library keeps foreground and background in one type, and it is the detail to read if you are porting from another library where those are separate calls.

Hex and HSL values convert to RGB as well, so you can take a colour from a design tool rather than hand-counting palette entries.

HTML tag markup lets you colour a whole string without splitting it

The distinctive feature is inline markup. The README supports HTML tag-style rendering such as `<green>message</>` and `<fg=red;bg=blue>text</>`, which means one string can carry several colours and a single call prints the whole thing.

// use style tag
color.Print("<suc>he</><comment>llo</>, <cyan>wel</><red>come</>\n")
// Custom label attr: 16 color names, 256 color values, rgb and hex values
color.Println("<fg=11aa23>he</><bg=120,35,156>llo</>, <fg=167;bg=232>wel</><fg=red>come</>")

The second line is the interesting one. It shows the same tag carrying a hex value in the foreground, an RGB triple in the background, a 256-colour index, and a named colour in one string. Built-in tags cover the named themes, and custom attributes reach the same three depths.

There is a related helper, `color.Tag("info").Println("info style text")`, which resolves a named style and applies it to a message without writing tags.

The trade-off is that this is a second string format layered on top of your format strings. A message that arrives from user input containing something that looks like a tag will be interpreted, and any place where you concatenate untrusted text into a message now has a formatting question attached to it. The library does not discuss escaping in the README, so treat tag-bearing strings as your own responsibility.

Named themes add Tips, Prompt and Block methods on top of Print

Beyond colour values there is a set of named styles: Bold, Black, White, Gray, Red, Green, Yellow, Blue, Magenta and Cyan, plus semantic names Info, Note, Light, Error, Danger, Notice, Success, Comment, Primary, Warning, Question and Secondary.

Semantic names get their own methods beyond the five generic ones. A theme style exposes `Tips`, `Prompt`, `Block` and `Println`, which are formatting conventions rather than colour operations: Tips for a short hint, Prompt for an input line, Block for a boxed message.

// print message use defined style
color.Info.Println("Info message")
color.Notice.Println("Notice message")
color.Error.Println("Error message")

// tips, prompt and block variants
color.Info.Tips("Info tips message")
color.Warn.Prompt("prompt style message")
color.Danger.Block("Danger block message")

Using `color.Info.Println` and `color.Error.Println` throughout a CLI gives you consistent severity colouring without touching raw colour codes, which is the library's clearest use case. Each theme section of the README has a matching runnable demo, such as `go run ./_examples/theme_tips.go`, so you can see the exact output before committing to a convention.

Custom combinations are still available for the cases the named themes do not cover, with `color.New(color.FgWhite, color.BgBlack, color.OpBold)` for a full custom style, and the shorter composite literal `color.Style{color.FgCyan, color.OpBold}.Println(...)`.

NO_COLOR and FORCE_COLOR decide before your code runs

Two environment variables control output globally. The README says the library supports setting `NO_COLOR` to disable colour, or `FORCE_COLOR` to force colour rendering on.

This is the feature that separates a small library from a thoughtful one. The convention of honouring `NO_COLOR` means a user who has asked their terminal not to emit escape codes gets clean output from every tool that follows it, and `FORCE_COLOR` gives you the opposite override for the cases where you know the destination supports colour and the environment has not detected it, which is common in CI wrappers.

Both are read before your code runs, so the decision is not something you have to thread through your own call sites. That is the point: a CLI that prints colour from twenty places does not want twenty checks for whether the output is a terminal.

What the README does not document is the precedence when both are set, or whether either overrides an explicit style attribute. If your CI sets `NO_COLOR` globally and you need colour in one specific command, that interaction is worth testing on your own pipeline rather than assuming.

A related low-level API exists for the cases where you want to set and unset the console state yourself, using `color.Set(color.FgCyan)` before printing with plain `fmt.Print` and `color.Reset()` afterwards.

Where this differs from fatih/color and from a TUI framework

gookit/color is a library for rendering colour in terminal messages, rather than for building a full-screen interactive interface.

The tag markup is another differentiator because it lets one string contain several colours. The README does not document how to handle tag-like text in user input.

For a tool that prints a handful of coloured lines and exits, gookit/color provides the colour APIs and Windows support documented in its README.

Editorial conclusion

Use gookit/color when your CLI targets Windows as well as Unix and you need the same rendering path on both, because 256 and true colour on CMD arrived in v1.2.4 and the Print-style API means no rewriting of existing fmt calls. Do not reach for it if you want a rich TUI framework, since this is a printing library and the examples are single-line messages rather than layouts. Before adopting, check whether NO_COLOR in your pipeline environment will silence the output your users rely on, since the library honours that variable and a CI log that suddenly loses colour is the most likely surprise.

Frequently asked questions

Official sources

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