alt.hn

1/29/2026 at 2:49:08 PM

How to choose colors for your CLI applications (2023)

 https://blog.xoria.org/terminal-colors/

by kruuuder

1/29/2026 at 4:54:21 PM

As long as CLI programs stick to the 8 or 16 standard colors and refrain from setting background colors (inverse mode is fine), as well as from explicitly setting white or black as text color, everyone can reasonably configure their terminal colors so that everything is readable.

When going beyond that, the colors really need to be configurable on the application.

by layer8

1/29/2026 at 5:57:24 PM

> refrain from setting background colors

That's the thing though, setting bg color opens up a lot of options, and constraining to invert is not sufficient in my opinion.

by JohnLeitch

1/29/2026 at 11:33:23 PM

Sticking to the \x1b[4X background color is probably safe as that can be tweaked by terminal color palettes. It’s when you use the 256 or RGB \x1b codes that it becomes an issue. Ok for foreground.

by reactordev

1/29/2026 at 6:13:12 PM

> constraining to invert is not sufficient in my opinion

Eh. Doing green/red text color with default background, maybe inverted works amazing for me. In fact, I'd say that every sensible colour scheme for a terminal should have as the default foreground/background colours something that is more or less contrasting against every other explicitly named colour, including black and white (I personally have #212121 on #EEEEEE).

by Joker_vD

1/29/2026 at 8:06:10 PM

Configurable within the application... at runtime.

I want to be able to switch existing terminals with existing applications between themes.

by Arch-TK

1/29/2026 at 3:20:53 PM

Use only default (white/black), red for bad, green for good. If you need more than that, like vim or whatever, then maybe a 'fullscreen' TUI is better, with a specified background and foreground. For CLI tools, I'm not sure if I prefer more colours.

The CSS to make the terminals look like iTerm was smooth, to the point I read them as screenshots.

by j4cobgarby

1/29/2026 at 4:04:46 PM

Hard disagree on the red/green. Use whatever you think appropriate and make it user configurable.

by BeetleB

1/29/2026 at 4:06:18 PM

It's a CLI app, it's already configurable. Every good terminal emulator lets you set custom palettes.

by mrob

1/29/2026 at 4:42:15 PM

>Every good terminal emulator lets you set custom palettes

Not differently for each program's output.

by kps

1/29/2026 at 4:48:20 PM

Which is a good reason to stick with the de-facto standard of red for bad and green for good.

by mrob

1/29/2026 at 5:03:24 PM

unless you're colour blind

by sceptic123

1/29/2026 at 5:27:17 PM

If you're color blind, you change the palette in your terminal emulator so "red" and "green" become different colors you can distinguish. It even works for rarer forms of color blindness. This works best when people follow the de-facto standard.

by mrob

1/29/2026 at 5:31:35 PM

Red here does not mean #ff0000. it means color 1. in the 4 bit colors palette

by skydhash

1/31/2026 at 10:22:19 PM

> Red here does not mean #ff0000

For you maybe.

"Look it is not gray on gray is black #777777 on white #333333". /s

by hulitu

1/29/2026 at 7:04:45 PM

If for something unrelated to good/bad looks good, I'm using red. Ditto for green.

Sure, if it was a status indicator and I used red for "good", I can see the point. But over the last few years I've had too many people tell me "Don't use red, people will think something is wrong" for things not semantically tied to good/bad.

People wear red clothes. They buy red cars. They eat red food. They date red heads. Red is OK.

by BeetleB

1/29/2026 at 3:36:01 PM

> red for bad, green for good

8% of men of Northern European descent (and 0.4% of women) are red-green colorblind. That'd be a terrible choice. Use blue-orange, blue-red, or purple-green.

by busterarm

1/29/2026 at 4:05:33 PM

This approach is worse. Use red and green like everyone else and the user can choose their terminal color palette to differentiate in a way that works for them. Then it works the same across all commands. If you're the odd one out, you're adding more mental overhead for the user, not less.

by Etheryte

1/29/2026 at 4:32:51 PM

You are ignoring that most people already have a cultural understanding of the colors red and green. Changes done for accessibility should never making things worse for the average user.

by account42

1/29/2026 at 3:48:39 PM

Red/green is semantic in these cases. They’re user configurable in almost all terminals, so there’s no real accessibility issue. I tend to associate blue with decorative accent, yellow with info/warning text, and cyan and magenta for really fancy stuff.

by skydhash

1/29/2026 at 3:52:33 PM

Red/green has no inherent semantics. It has the semantics that you assign it. If you choose to assign it meaning that disenfranchises 8% of men using your system, that's your choice, but it is not a good one.

by tczMUFlmoNk

1/29/2026 at 3:58:48 PM

Cultural semantics (diff tools, build tools,…: green/addition/ok, red/removal/error). And people with color blindness can alter the colors to something they can differentiate. And in the ansi sequences, they are actually numbers.

by skydhash

1/29/2026 at 4:04:50 PM

The standard terminal palette is only 16 colors. Even if you compress them all into the green-to-blue color range, it's still possible to distinguish all 16. The user can change "red" and "green" to whatever they like in the terminal preferences and then every 16-color app will be accessible with no additional effort from anybody.

by mrob

1/29/2026 at 3:41:14 PM

More importantly, dont use color as sole source of information. Strikethrough, emoji or ok / bad can also be used.

by makapuf

1/29/2026 at 3:58:05 PM

Emojis aren't 7-bit clean. They're hard to type. They don't mean things the same way words do. `foo | grep -i error` communicates intent better than `foo | grep :-/` or whatever goofy hieroglyph someone chose instead of, like, a word with clearly defined meaning.

by xenophonf

1/30/2026 at 5:45:02 PM

In my experience with live codebases, "error" or "warning" rarely mean the same thing to the same person, but admittedly you're much more likely to guess that they're in use as opposed to crying-green-clown emoji

by wredcoll

1/29/2026 at 4:29:04 PM

> They're hard to type

I'd like to recommend rofimoji. I have it bound to a hotkey, so whenever I want to type an emoji, I just hit that hotkey and then a window pops up with my most recent emoji already visible at the top. Then I start typing in words that describe the emoji that I want like "crying" and it filters the list. Finally I select one and it pastes it into whatever text box I had selected before I hit the hotkey. My only complaint is I wish it worked for all unicode codepoints instead of just the emoji.

by craftkiller

1/29/2026 at 5:41:30 PM

Yes that's why I also mentioned text labels. (strikethrough ansi codes aren't also fun to type). Besides, where are you needing 7but clean data ? Isn't that a narrow use case ?

by makapuf

1/29/2026 at 8:51:20 PM

> They're hard to type.

Globe key + E on Mac, Windows key + period on Windows, Ctrl + period on GNOME, Super key + period on KDE, yada yada.

by Lammy

1/29/2026 at 5:04:17 PM

Color is cultural. Red is associated with good in China

by fassssst

1/29/2026 at 5:16:39 PM

Context here matters, red finds its way into Chinese forbidden or warning signs quite often.

by altcognito

1/29/2026 at 4:13:02 PM

Eh, LS_COLORS is sometimes useful once the meanings are in your subconscious.

by red_admiral

1/29/2026 at 5:51:53 PM

A confused user once stopped by, they had a blank terminal, so I showed them how to select all which revealed the helpfully black on black text. These days I compile colour support out of st, or set *colorMode:false for xterm. "But you can customize the colours" is a typical response, to which one might respond that one has grown weary of pushing that particular rock, and moreover one may be busy with other things at a drag-out monitor in a server room at three in the morning that has helpfully dark blue text on a black console, or worse if some high-minded expert has gone and rubbed the backside of a unicorn everywhere so that they may improve the "legibility".

by tolciho

1/29/2026 at 5:12:25 PM

Colourful terminals are so useful. I have mine colour coded according to the working directory depending on the project. So I can see which terminal is associated with which project even if there are twenty terminals open. The scripts are even in my servers so when I ssh in to them it changes colour as well.

https://michael.mior.ca/blog/coloured-ssh-terminals/

by s_dev

1/30/2026 at 12:16:07 AM

Very cool. Thanks for sharing!

by kiddico

1/29/2026 at 4:09:49 PM

There's an ever more basic rule: don't just make your text white (ANSI 37m) because you assume the terminal will have a dark background. Even white-on-black (37;40m), while usually readable, can stand out the wrong way if you assume that everyone is using dark mode.

by red_admiral

1/29/2026 at 4:23:31 PM

IMO if your terminal theme does not provide high contrast for "white" text on the default or "black" backgrounds, that's for you to fix. If you want a light terminal then change the color scheme to map "black" to a bright color and "white" to a dark color while making sure that other colors have good contrast to your "black". Don't just change the default foreground and background color and expect every single color using program to fix your mess.

by account42

1/29/2026 at 5:31:20 PM

As long as you respect the NO_COLOR variable, it will work for me.

https://no-color.org/

by ori_b

1/30/2026 at 5:48:13 PM

That's a funny example. I have no issues with the idea of course but in my day to day life I'm way more likely to encounter an issue with colors being lost after sent to a pager or a log file or tee or what not

by wredcoll

1/29/2026 at 4:58:23 PM

I'm a bit color blind and it might be quite common to show errors in red but when the background is black, I can't see it at all.

by jammcq

1/29/2026 at 5:09:19 PM

Neither can I. Luckily tweaking the colours can make it somewhat readable. (Sometimes…)

by bradrn

1/29/2026 at 9:43:59 PM

I made the "Aardvark Blue" a while back[1] to solve some of the problems that most color schemes have. The goal of this theme is that:

- colors are fairly natural

- background and black are distinct

- grays are naturally ordered avoiding full black

- light and dark colors are distinct from each other

- all colors look good on background, black, dark gray, gray, white

We use this for all the screenshots on https://ratatui.rs and https://github.com/ratatui/ratatui

It's available from the usual places https://iterm2colorschemes.com/, https://windowsterminalthemes.dev/?theme=Aardvark%20Blue, built in to ghostty, extension for vscode etc.

[1]: https://github.com/mbadolato/iTerm2-Color-Schemes/pull/417

by joshka

1/29/2026 at 10:21:57 PM

Funny thing, those are not "the usual places" I've ever heard of, and I care somewhat about color schemes. Each of us lives in our own bubble... (my bubble is not iterm2 and not windows)

by tasuki

1/31/2026 at 2:54:35 AM

iterm2colorschemes is a source for various other tools as it ports out to

"Terminal, Konsole, PuTTY, Xresources, XRDB, Remmina, Termite, XFCE, Tilda, FreeBSD VT, Terminator, Kitty, MobaXterm, LXTerminal, Microsoft's Windows Terminal, Visual Studio, Alacritty, Ghostty, and many more."

You may have used data from it without knowing about it.

by joshka

1/31/2026 at 3:05:09 PM

> You may have used data from it without knowing about it.

Plausible!

by tasuki

1/31/2026 at 4:42:59 PM

Yeah, when I created that repo, it was for me to store iterm themes that I found, and it took off and got ports to, well, pretty much every terminal . I didn't want to rename the repo since it's linked to in so many places. The main link people usually see is iterm2colorschemes.com but I do own terminalthemes.com and should probably just get around to pointing that one to the repo, too

by bado

1/30/2026 at 10:52:58 AM

Where are some of the usual places you look?

by ctmnt

1/29/2026 at 10:38:32 PM

The problem with CLI colors is that they operate on the wrong abstraction layer. Individual program shouldn't send "this text is red" but "this text signals failure" and then terminal interprets "failure" as "red". Until this change happens (never) colors in CLI will remain a hot mess.

by anal_reactor

1/29/2026 at 5:48:03 PM

I really think we should converge to semantic codes. By example Background is zero, standard is 7, positive / negative, highlight, colored1,2,3 .. with correct defaults, and let the user have a common 8 or 16 colors palette in the terminal for all textmode apps. Imagine having some kind of unified color themes in the terminal.

by makapuf

1/29/2026 at 6:32:09 PM

I’ve bounced off of LazyGit multiple times because I never figured out how to make it play nice with a light theme terminal.

I haven’t used dark mode anything for years. I set my monitor so it’s roughly as bright, or slightly brighter than, a piece of white paper.

No more flash-bangs when some website doesn’t support dark mode.

by nateroling

1/29/2026 at 3:54:10 PM

I really wish you wouldn't. All the rinky dink colors and animations screw with the CLI output when you don't correctly detect whether the user's running the app interactively.

Keep it plain text. Regular, old, boring output is good.

by xenophonf

1/29/2026 at 5:24:50 PM

I dislike when devs only try to detect if it’s a tty, then enable all their gimmicks without even providing a flag. Not everything is xterm-256color.

by skydhash

1/29/2026 at 6:10:01 PM

And not everything that calls itself xterm-256color is actually xterm compatible *cough* GNOME *cough*.

by kps

1/29/2026 at 7:26:04 PM

Xterm is actually a terminal emulator, and has to pass a suite of conformance tests that actually check its emulation of DEC VT series terminals.

Most of its successors are more like "shitty xterm emulators" whose conformance tests are "do my favorite mOdErN CLI apps work".

by bitwize

1/29/2026 at 7:24:06 PM

I agree. So many TUIs from webshit devs don't even bother to call isatty, let alone check terminfo to see if ANSI escape codes are even valid for this terminal.

But modern open source subscribes to Mao's Continuous Revolution Theory. Calls for some measure of stability and sanity are usually dismissed with some form of the argument "awwww, is poor diddums afwaid of a widdle change?" Or in this case, "still using vi on your ADM3A, old timer? Our software is not for you."

by bitwize

1/31/2026 at 7:09:40 AM

Emacs on a Link MC5, although something doesn't like how the terminal handles flow control. I'm not sure if it's the O/S, the UART, the cable, or the terminal, but I have issues with I/O corruption. Even something a simple as a directory listing will get messed up, and on both FreeBSD and Linux, so maybe that rules out the O/S. Oh well. I'll figure it out some day.

by xenophonf

1/29/2026 at 5:42:10 PM

Yeah. "The only winning move is not to play".

by davidw

1/30/2026 at 4:00:29 AM

Big blocks of text are difficult to parse

by bl4kers

1/31/2026 at 7:06:03 AM

Not with sed and awk they aren't.

by xenophonf

1/29/2026 at 4:31:32 PM

I recently spent several evenings re-working all of my colours across all of my computers and screens; terminals, IDEs, etc. Ultimately, despite using the same tools, and always dark mode, across all of my machines, the setup for each was different.

I think it's safe to set a standard colour-set so that it's immediately usable, but beyond that, a user should be customising to their requirements.

Perception differs among people; many of the colours OP listed as unreadable, were barely an issue, bright yellow being the only one I could unequivocally agree on. Perhaps display type, configuration and colour calibration is an important factor, as well as individual perception, ambient conditions, brightness levels, contrast, and perhaps even more variables have a significant effect.

I've also learned, since adding an OLED Monitor to my desk alongside the IPS ones, that it's possible to have too much contrast; brightly coloured text alongside pixels that are literally off can be just as problematic to read at times, as low-contrast.

by alias_neo

1/29/2026 at 5:36:17 PM

If you want a quick easy way to add some colors to your own shell scripts:

    export STDOUT_COLOR_START=''
    export STDOUT_COLOR_STOP=''
    export STDERR_COLOR_START=''
    export STDERR_COLOR_STOP=''
In your shell script:

    print_stdout() {
        printf %s%s%s\\n "${STDOUT_COLOR_START:-}" "$*" "${STDOUT_COLOR_STOP:-}"
    }

    print_stderr() {
        >&2 printf %s%s%s\\n "${STDERR_COLOR_START:-}" "$*" "${STDERR_COLOR_STOP:-}"
    }
Source: https://github.com/sixarm/unix-shell-script-kit

The source also has functions for nocolor, and detecting a dumb terminal setup that doesn't use colors, etc.

by jph

1/29/2026 at 5:49:33 PM

1. That script's color check doesn't check that the output is a terminal. Also test

    tty -s
2. Don't hardcode escape sequences. Use (e.g.)

    export STDOUT_COLOR_START="`tput setaf 4`".

by kps

2/3/2026 at 9:34:53 PM

Yes good points both, thank you. The source code link has more explanation about color choices and my preference of POSIX compatibility. You can also see the color function that checks NO_COLOR, CLICOLOR_FORCE, TERM = "dumb", -t 1, etc.

For color operands, I use raw escape codes because I aim for POSIX compatibility. If I'm working on something that needs more capabilities then I switch to a more powerful programming language e.g. python, rust, etc.

As far as I understand, POSIX tput defines some terminal operands (clear, init, reset, etc.) but not color operands (setaf, setab, sgr0, etc.).

by jph

1/29/2026 at 6:39:55 PM

If you're writing a zsh script and not worried about portability, you can also use the prompt expansion colors with "print".

    print_color () {
      print -P "%F{$1}$2%f"
    }
And then to use it

   print_color "green" "This is printed in green"

by wpm

1/29/2026 at 7:57:46 PM

Here's something also useful that's portable

  declare GRN='\e[1;32m'
  declare RED='\e[1;31m'
  declare YLW='\e[1;33m'
  declare CYN='\e[1;36m'

  write_log() {
      echo -e "[$( date +'%c' )] : ${1}\e[0m" | tee -a ${logfile}
  }

  write_log "${RED}I'm an ERROR"

by godelski

1/29/2026 at 6:59:04 PM

Nice. I put this in my .zshrc.

by leephillips

1/29/2026 at 8:16:53 PM

That seems needlessly cumbersome, why not

  declare STDOUT_COLOR='\e[34m'
  declare STDERR_COLOR='\e[31m'
  declare COLOR_STOP='\e[0m'

  print_stdout() {
      echo -e "${STDOUT_COLOR}${*}${COLOR_STOP}" &> /dev/stdout
  }

  print_stderrr() {
      echo -e "${STDERR_COLOR}${*}${COLOR_STOP}" &> /dev/stderr
  }
Like why are you exporting? Do you really need those in your environment?

And those print statements aren't going to work by default.

by godelski

2/3/2026 at 9:50:59 PM

Good questions.

For shell syntax, I aim for POSIX because for anything more advanced I switch from shell to a more powerful programming language.

Currently POSIX doesn't have the 'declare' statement, nor the '\e' syntax consistently, nor the 'echo -e' syntax consistently.

As for exporting, I do it because I have many quick scripts that I run often, and I prefer to switch the colors in one place such as in the evening from light mode to dark mode.

When you say the print statements aren't going to work by default, can you say more about this? Anything you can explain or point me to about this will be a big help. Thanks!

by jph

1/29/2026 at 5:40:20 PM

What is the purpose of making everything the same color?

by direwolf20

1/29/2026 at 5:42:41 PM

stdout and stderr get different colors.

by Rygian

1/29/2026 at 5:24:13 PM

Interesting analysis, but perhaps it warrants a different conclusion: it's almost impossible to please everyone in this case. The resulting colours seem of some utility, but if you intend to make something more interesting you're probably annoy some (potentially large) group, in the case of legacy terminal coloring.

by thinking_cactus

1/30/2026 at 2:40:01 PM

In addition to $TERM, I wish there was a standard variable defined by terminal emulators that would contain the background color. This would let programs choose their colors accordingly, rather than try for a one-size-fits-all.

by loicd

1/29/2026 at 5:25:48 PM

I used solarized since it came out but I dropped it some years back. I don’t think I can use it for dark mode. It’s too washed out and dull compared to light mode which is what I used to use it with. I just use whatever VS Code or VIM gives me as a dark mode and it’s usually better.

by hnsmhthrow

1/29/2026 at 10:57:49 PM

Use 8 or 16 standard colors, let me configure them via terminal emulator or give me a way to completely change color scheme. That is it. Very rarely I need per-application colors in terminal (or anywhere really).

by 0x457

1/29/2026 at 7:15:51 PM

Black on white has seemed to work for centuries without issue. For general reading, throw in bold and italic and you're pretty much set. For programming, black on white is still a go to color (or lack thereof).

by assimpleaspossi

1/29/2026 at 4:05:36 PM

If the goal of the post is to pick terminal colors that contrast on both white/light and black/dark backgrounds, it means you're stuck with midtone colors (between light and dark). This is really limiting for color choice (there's no such thing as "dark yellow" for example), and lowers the maximum contrast you can have for text because you get the best contrast when one color is dark and the other is light.

Ideally, instead of the CLI app switching to "bright green", it would pick a "bright contrasting green". So if the terminal background was dark, it would pick bright green, and for light background it would pick a darker green. There isn't CLI app implementations for this? This is similar to how you'd implement dark mode in a web app.

by seanwilson

1/29/2026 at 4:25:20 PM

> Ideally, instead of the CLI app switching to "bright green", it would pick a "bright contrasting green". So if the terminal background was dark, it would pick bright green, and for light background it would pick a darker green. There isn't CLI app implementations for this? This is similar to how you'd implement dark mode in a web app.

The responsibility for this lies with the color scheme not the terminal program.

by account42

1/29/2026 at 4:49:46 PM

CLI apps can detect the background color of the terminal, and determine contrasting colors accordingly.

by JoshTriplett

1/29/2026 at 4:54:19 PM

They can? Is this a recent thing? I remember wanting to detect the background colour years ago, and not finding any way to do it.

by takluyver

1/29/2026 at 5:01:43 PM

It's not recent, and most terminals support it. You send an escape sequence to the terminal, and get back a sequence that tells you the exact background color.

by JoshTriplett

1/29/2026 at 4:23:51 PM

That's called `\e[0;92m`, aka the ANSI terminal espace sequence for bright green. You have 15 others, that will be displayed however the terminal's user wants. They're already available in most terminal color libraries, too.

by alt187

1/29/2026 at 3:55:56 PM

This is true for the console in dev tools as well.

Problem there is you can’t change css so at the moment the systems color preference changes thing will look bad.

Important considerations for custom formatters.

by sroussey

1/29/2026 at 4:12:30 PM

It's 2026, and app developers are solely responsible for not causing eyehurt, even if their users insist on using the Hotdog Stand theme.

by bitwize

1/29/2026 at 6:07:29 PM

Tangential, but I really love the design of this blog.

by munificent

1/30/2026 at 10:17:20 AM

Me too. Typography and colors are great.

by alfirous

1/30/2026 at 1:59:29 AM

What is Sorcerer here?

by pimlottc

1/29/2026 at 6:13:12 PM

Step one: *always* assume a dark background.

by otabdeveloper4

1/29/2026 at 4:43:44 PM

[dead]

by maximgeorge

1/29/2026 at 7:41:25 PM

I use the built-in TokyoNight Day theme as my light theme in GhosTTY and I think it's almost perfect. Then I use TokyoNightMoon for dark. Works great. Hard to use anything else now.

If you're CLI application doesn't play nice with it (i haven't seen many) I don't use it.

by lifetimerubyist

1/29/2026 at 3:32:53 PM

[flagged]

by the_gipsy

1/29/2026 at 3:51:01 PM

It's easier to see dark text on a light background for people with astigmatism.

by taswellian

1/29/2026 at 4:50:57 PM

Or for people working outside. Or for people using an e-ink display.

by JoshTriplett

1/29/2026 at 3:36:23 PM

Most things work fine with black on white terminals.

If your software does something dumb when my theme switches to black on white during the day then I am just going to avoid using it...

by Arch-TK

1/29/2026 at 3:53:14 PM

Accommodating terminal colour schemes, however crazy to you they might be—white on black, black on white, dark brown on off-white Solarized-style, etc.—is basics of TUI design.

Personally I alternate between light on dark and dark on light (the latter sometimes together with OS-wide colour inversion feature).

by strogonoff

1/29/2026 at 3:54:02 PM

> People who use white themed terminals are psychopaths anyway

Dark background is hell for anyone with astigmatism. It’s fine with 80x24 (vga text mode), but for anything higher feels like light needles on the retina. With astigmatism everything that is bright and small is duplicated, which means small characters is very difficult to read.

by skydhash

1/29/2026 at 4:18:11 PM

Can you work this into an AGENTS.md ? Just so happen to be working on multiple TUI at the moment: text-based modern web browser, VPS rental console, agentic coding wrapper.

Colors, have been a perpetual nightmare.

by keepamovin