My experience is that CLIs were typically shown with light text on a darker background. For example, the IBM PC would use white/light gray (depending on your point of view), amber or green (the latter two for monochrome monitors) on black unless the software did something to change that, and the Commodore 64 IIRC used white on blue, and the original Amiga Workbench used white on blue for the CLI.

Yet once GUIs started taking off, the typical color scheme seems to have been dark text on a light background. For example, even early versions of Microsoft Windows used black on white; apparently, so did GEOS on both the C64 and on the Apple II; as well as Digital Research's GEM. The Amiga soon switched to a black on grey color scheme. One major exception seems to have been Visi On using a white on black color scheme for much of the UI, including the bundled applications.

I do remember some time in the mid-1990s using a PC compatible which used black text on a white (or at least light) background for the MS-DOS CLI, and that really was the odd one out.

Why did early CLIs seemingly so predominantly use light on dark color schemes, and what drove the shift to GUIs using dark on light color schemes instead?

  • 33
    Not a full answer, but the resolution of early computers did not support a good looking white background, i.e. there were too many gaps between the scanlines. Also, the desire for WYSIWIG to represent printed black ink on white paper drove GUIs to adopt dark on light color schemes.
    – Glen Yates
    Commented Sep 14, 2018 at 20:32
  • 3
    I have no authoritative source on this but my view of it has always been that light on dark was simulating the “green screen” terminal look, and the dark on white of GUIs was simulating print/writing on paper.
    – mannaggia
    Commented Sep 14, 2018 at 20:32
  • 4
    The Sinclair range of computers (except the QL, maybe, that opened both types of CLIs) all had consoles black on white. You could, however, re-solder a jumper wire on the ZX-80 to invert the screen.
    – tofro
    Commented Sep 14, 2018 at 20:46
  • 3
    Oric Atmos and Dragon 32 had black-on-white (the latter black on light green) defaults
    – tofro
    Commented Sep 14, 2018 at 20:53
  • 5
    @StephenKitt: The CGA would blank the entire screen to black when scrolling text, which was ugly when the background wasn't black. On a related note, some machines force the output to black whenever they write anything to the screen. That is far less noticeable when showing text with a black background than when showing text with a white background.
    – supercat
    Commented Sep 14, 2018 at 22:37

9 Answers 9


Why did early CLIs seemingly so predominantly use light on dark color schemes, and what drove the shift to GUIs using dark on light color schemes instead?

Simple: CRT technology (and, as so often, missing the need to do otherwise)

Early CRT technology was not able to deliver black on white. Further it was more important to make a readable display early on, than a paper-like one – an idea that only became a topic many years later.

On a CRT the 'lightened' parts are the ones drawn by the electron gun. Writing the few strokes of a letter can be done with a beam whose focus is wider than a pixel, as the large dark areas will give a good contrast. In fact, this will even improve quality, as adjacent pixels will form a coherent line when spilling.

Changing between off and on and back didn't need to happen exactly at the border of a pixel and as instantly as possible. If ramping up voltage to draw a pixel left a blur, it didn't matter, as long as the sufficient intense part was at least as wide as a pixel and (hopefully) smaller than two of them. CRTs, CRT controllers and analogue parts in between got thus a rather low requirement for exact justification and maximum switch frequency. And that's what the emerging technology could deliver. As a result, all early screens were white (or whatever the light emitting surface was) on black.

Illuminating the 'background' to produce black on white, on the other hand, does need a way faster ramp up (and down) time for the electron cannon to allow sharp borders, as well as way more exact focusing, as now a lighted pixel should not spill over (which would have made the black letters unreadable), but at the same time no black gap between pixels should be visible/produced. Last but not least, the gun, as well as the power electronics for the CRT, need to be sufficient sized to supply a screen that is mostly while (*1).

One of the basic ideas of a GUI is the paper metaphor, presenting documents to the user that look as much as possible like the paper on his desk. And we're used to writing dark on white (or at least light coloured) paper. Thus the requirement for high quality screens came to satisfy this.

For a ~1980, GUI based workstation, the CRT did cost almost as much as the whole computer – but was necessary to provide an acceptable picture for daily professional use.

Screens sold for early desktop computers, from Apple II to the PC, were not really made to satisfy the needs – even if the computer could supply a 'sharp' image (high switching frequency), the CRT couldn't display it. Trying black on white (or green) on an Apple II with an early 80s '80 column' display was quite painful. This screenshot of Mousepaint on a contemporary CRT gives a hint. Similar to doing so on a MDA/Hercules PC. Sure, it could be done, just not acceptably so for a professional environment (*2).

That's also the reason why not only Visi-On used a white on black output in their windowing, but also Apple for their GUI-ish programs on the Apple II (Mousetext). Heck, even Microsoft offered a (mostly) white on black screen layout for Windows. The colour pictures we get shown today were only that good on high end graphics cards and really good screens.

The default white on blue colour scheme for the Amiga was not at least due to the need to look good on affordable screens. Atari flunked out by using a specially designed b&w screen. It took some time until higher resolution CRT controllers, together with better screens, became available for mainstream computers.

... and no time in the world can change deep rooted habits, like wanting your CLI as white on black :))

*1 - I guess everyone remembers pumping screens when content changed - and worse, such with not enough 'light' to really fill large areas resulting in a sludgy grey in grey display.

*2 - No, just because we did endure it out of coolness doesn't mean it was acceptable.

  • 7
    To amplify your earlier point: if a CRT goes from 5% to 75% when drawing the vertical portions of a character, but manages to go from 5% to 100% for the horizontal portions, the contrast for the vertical part will be 15:1 versus 20:1 for the horizontal parts. Not wonderfully even, but not horrible. If the CRT goes from 100% to 25% for the vertical parts at 100% to 5% for the horizontal ones, then the contrast would be only 4:1 for the vertical parts vs. 20:1 for the horizontal parts. Much worse.
    – supercat
    Commented Sep 14, 2018 at 21:22
  • 7
    What is "pumping screen?" Commented Sep 14, 2018 at 23:45
  • 17
    On top of all this Early CRTs had not as durable luminofors as we know today which often lead to burned images into CRTs (especially if typical app was used on daily basis). That was the main reason for Screen savers. Using white background on such CRTs leads to significantly shorter life span of the CRT (gradually darkening the image).
    – Spektre
    Commented Sep 15, 2018 at 0:12
  • 4
    @WayneConrad Ouch. Extrem clear if you seen it, hard to explain otherwise. I try a simplified version. A CRT works by aplying a voltage between anode and cathode to emit electrons which then get focused and deflected to to draw the picture. To controll the amount of electrons the voltage gets variated by another part. Simple so far, but the amount of electrons (or better their energy) backcouples to the deflection circuit, changing the amount of deflection depending on the brightness of the picture displayed. Changing the amount of light and dark parts will thus resize the picture.
    – Raffzahn
    Commented Sep 15, 2018 at 0:16
  • 5
    @WayneConrad There are ofc ways to controll this, but they increase complexity of the CRTs electronics. After early load triodes, modified flyback transformers where used to controll this effect. Now, if a picture doesn't change much (unlike a TV), a simpler (aka cheaper) setup can be used. On a white on black text screen, the picture rarely gets abouf 15-20% total brightness, so this was a chance to simplify electronics, or more exact buy less expensive components (lower current diodes ). Kapitalism at it's best .
    – Raffzahn
    Commented Sep 15, 2018 at 0:26

From the Macintosh Folklore Site:

The Apple II displayed white text on a black background. I [Bill Atkinson] argued that to do graphics properly we had to switch to a white background like paper. It works fine to invert text when printing, but it would not work for a photo to be printed in negative. The Lisa hardware team complained the screen would flicker too much, and they would need faster refresh with more expensive RAM to prevent smearing when scrolling. Steve listened to all the pros and cons then sided with a white background for the sake of graphics.

As white filled the screen (or green, or amber), any flicker became more obvious and annoying, and the inexpensive workarounds usually weren't much better. It was easier to just stick with white/green/amber letters on a black background. So black-on-white was an expense that wasn't justified in the era of the CLI but later became necessary for GUIs.

  • 1
    Here's a similar answer to a different question: retrocomputing.stackexchange.com/a/3264/75 Commented Sep 15, 2018 at 5:26
  • But the flicker can also be reduced by using a longer-persistance phosphor, as IBM did with their original MGA. Doing this was certainly easily possible (though I don't know what the effect on cost would be) for the early Macs, where Apple always supplied the monitor. so why would Apple not just solve the problem with a longer-persistence phosphor?
    – cjs
    Commented Aug 29, 2019 at 23:06
  • 1
    @CurtJ.Sampson Because it would cause smearing while scrolling. Commented Aug 29, 2019 at 23:21
  • I don't understand why there would be flicker with a white background but not a black background?
    – rasen58
    Commented Aug 22, 2020 at 1:19
  • 1
    @rasen58 the black parts of a screen stay black at all times, while the lit parts are only lit when the raster beam passes. So, for a white-on-black screen, a small percentage of the screen is flickering, but on a black-on-white screen, the vast majority flickers. Commented Jan 20 at 19:50

I won't get into details of why white on black, as others have explained that this mostly due to limitations of CRT technology at the time.

One of the main reasons for the switch to black on white in GUIs, though, is skeuomorphism: GUIs (especially the early ones) tried very hard to emulate real-life, and have lots of things like folders, trash bins, and more that come from the original tools they're trying to replicate/replace, which obviously includes the existing (white) paper with (usually) black text printed on it.

One of the big keywords at the time was also WYSIWYG: What You See Is What You Get, which was the big difference with text-based interfaces available till then. You had actual fonts, sizes, styles, etc, and it should look the same on screen and when printed. That meant black on white.

Once you have most of the interface that is black on white (word processing windows, spreadsheets, technical drawings...), then it's quite natural that the rest of the GUI (menus, dialogs...) should be the same.

Of course there's a bit of a tendency to go back to white-on-black nowadays. Makes you look cool™.


Since nearly all early computers used TV quality CRT screens, they suffered from phosphor burn in so the more you limited visible areas the longer your CRT would last. More expensive higher quality monitors had less of a problem but the price tag did not appeal to the mass market.

The early TV quality monitors had pronounced flicker and many video card refresh rates were slow enough to be seen. Using a black screen helped hide these deficiencies. When graphics became more popular the switch was mandatory. With the exception of Apple, the first black on white screens I saw where X11 terminals the latter part of 1980's.

  • 5
    Reminded of this by the mention of X-terminals: at the professional end, Sun workstations also used white backgrounds from the end of the 80s: the Sparcstation 1 (launched 1989) being the one I'm most familiar with definitely used light coloured backgrounds in console mode (but then the machine was never designed for console use -- it only had a graphical framebuffer, and console scrolling was too slow to be usable, so you could only really do any productive work on the machine in X).
    – Jules
    Commented Sep 15, 2018 at 16:47
  • 1
    @Jules The black-on-white console on Suns goes back at least as far as the introduction of the Sun 2 workstation in 1983. (I've never seen a running Sun 1 in the flesh and wasn't able to dig up a photo. Those may do the same.)
    – Blrfl
    Commented Sep 17, 2018 at 11:33
  • White on black was probably also more practical on late-80s Sun workstations because two display options were offered: a more expensive colour system that was of about average quality for a workstation at the time and a cheaper monochrome system that was significantly sharper (than both the Sun colour system and even the IBM PC MGA systems of the time). I owned both and used mainly the black-and-white one for text editing because black text on a white background looked very good on it.
    – cjs
    Commented Sep 18, 2018 at 6:32
  • 1
    Shouldn't this say "the first black on white screens I saw" ...?
    – mdd
    Commented Sep 18, 2018 at 19:27

The Raffzahn's answer perfectly desribed why white on black CLI was result of technical limitations, and better technology together with GUI went for black on white.

I would like say more about, why even now is CLI white on black.

The main aspect of GUI is, that it is designed mainly (mainly) for content consumers. The screen should look "nice" and many times there are tone-in-tone colors used

Look at this site:

  • the footer here is blue text on blue background, using 3 tones of blue and one grey, which does not stand out (yes and black titles too)
  • The header is grey on black mainly.
  • The main page use lot of gray items on white and lot of light blue items too.

Web pages, GUI tools and such today looks decent, professional and all (but some people with bad seeing have problems to read those so much decent shades), they also use the bonus of having 24-bits colors and would not fit to old 16, or 256 colors paletes as good.

All of it is mainly supposed to be processed by human eyes, so it prefere "niceness", knowing, that humans have extra strong "autocorrection ability" for reading, and that there is not problem, if some of similar characters (like .,;: or l1I|) looks nearly the same. Consumer will probably read the right version, even if actually wrong is used. The same goes for typos - many of them are just ignored or not recognized at first reading and it is not a problem - the right message will go thru anyway. Even if there are some elements to manipulate, they are typically big buttons or full words/phrases in different color (hyperlinks) and the consumer have just to choose from this selection offered and hit with mouse relatively big rectangle - somewhere.

And majority of text (if not all) is ment to be read fast, not preciselly deciphered to last character. Well, for exact copy there are Copy-Paste shortcuts, no need to make sure each character fits - just make sure, that the begin and end is right.

On the other hand CLI is maily used by programmers to be read by computer.

And computers do not have good autocorrection (and it would not be typically used in CLI commands/programs anyway, as the each character counts and using other, just visually similar, would probably make an error in the best case, unwanted (but legal) difference in worse case.

(Old good

rm -rf test *

shows how one more space give totally different and harmfull (but syntactically correct) effect. )

So CLI prefere exact results and correctness over nice look. And usually is even set to bigger font and syntax highliting and just few bright, distintive colors on black (or dark) background. All for making harder to any mistake slips. The small number of bright colors on black backgroud makes everything highlited to really stand out and be totally distinctive from any other kind of highlites.

Those texts are supposed to be correct to last character and to be deciphered and weighted with extra care.

At least me and every other programmer, who I know have its programming evironment set it similar high-contrast scheme, while "normal web pages" are in "nice, decent tone" at the same time.

The dark background makes the bright collors (white, magenta, red, cyan ...) stand out more, then white backgroud, or even "old sepia picture with hint of light blue here and light pink there" background, which is to be seen an many webpages.

The relative small number of colors (and only few cases of inverted background on the most critical spots) make it easier to distinguish exact meaning of such marked phrases, words or even single characters.

So the result for "darker gray on lighter gray" GUI and "bright on black" CLI is not only result of nostalgia, but also (and mainly) result of different use (reading vs. programming) and different targets (readers vs. computer programs)

BTW, if I remember correctly, than Spectrum BASIC was black on white (and bad readable too) as well as some other examples and lot of old BIOS screens. TurboPascal used Yellow on Blue for text and Black on White for menus in days, where Hercules cards was common here and lot of PCs had CGA graphic cards, just few had VGA one. So other approaches also existed in old good times :)

  • 8
    The main aspect of GUI is, that it is designed mainly (mainly) for content consumer <-- this is sheer snobbery. Pretty much all the books and documents in the world are written on GUI systems these days
    – Gaius
    Commented Sep 15, 2018 at 10:41
  • 3
    White on black may be fine when you are typing critical commands into terminal, but staring into it for hours is not very good for your eyes.
    – IS4
    Commented Sep 15, 2018 at 13:37
  • The Spectrum (and IIRC it's predecessor the ZX80) was indeed black on a white background.
    – Pete
    Commented Sep 15, 2018 at 16:51
  • 1
    "Spectrum BASIC was black on white (and bad readable too)" - actually black on grey, You could change the colors, but analog TVs tended to go out of focus at high brightness and strong colors bled so the default scheme worked best. Commented Sep 16, 2018 at 19:06
  • 1
    @IllidanS4 lots of programmers spend all day hacking, using a dark background. It's just as good (or bad) for the eyes as a white background. In either case, the trick is to not keep the eyes fixated on the screen all the time, but briefly glance somewhere more distant in frequent intervals. This comes more naturally if the environment has a similar brightness as the screen, that's why in a well-lit office a white background can be perceived as being somewhat easier on the eyes. However you're working in a darker room, black background works much better. Commented Sep 17, 2018 at 19:25


Tandy CoCo / Dragon 32: Coco DOS startup

ZX Spectrum: Speccy BASIC listing

  • 2
    Looks great in Emulation on a LCD screen, doen't it? Now try on contemporary Screens - and crossreference what has been said about resolution. (SCNR)
    – Raffzahn
    Commented Sep 18, 2018 at 12:59
  • 1
    I wasn't commenting on technical reasons, just providing counter-examples. I had both, and they looked not bad on a PAL TV. The Speccy had fairly hideous dot-crawl, but that was a feature.
    – scruss
    Commented Sep 19, 2018 at 0:25
  • Which is not to mention: image.ibb.co/heqXge/Oric.png image.ibb.co/mf3DnK/Vic_20.png ; we had a 128kb Spectrum (i.e. no dot crawl) and never a problem on late-'80s TVs. (EDIT: definitely don't hesitate to edit those into the answer if you think they're relevant)
    – Tommy
    Commented Sep 19, 2018 at 0:28
  • @Tommy depends on the TV model and year of release. the newer TVs where usually fine (unless you specifically know what to look for). But the old ones did not. Also country makes a big difference as designs and parts where not the same in comparison between RVHP and Western Europe/America also the voltages and frequency makes some impact on this. However TVs where usually slightly better than computer monitors as TVs where mass produced at that time and monitors was only to be in their rise at least in my part of the world.
    – Spektre
    Commented Sep 20, 2018 at 7:24
  • @Tommy On my ZX I preffer the White on Black configuration instead of the default Black on White. I got an old TV for it (light bulbs) at that time and pumping was visible/hearable but the major cause for this was that my sight was much less tired with such. This custom is prevail in me. The pumping was not a biggy as there where not much many programs that would change the overall brightness of the screen too much at once so it was not so obvious unless you look for it (like during border change from black to white or vice versa). The lower resolution helped with the slower beam supply
    – Spektre
    Commented Sep 20, 2018 at 7:31

As soon as multi colour printers became available the WYSIWYG paradigm required the background to be white.

It was not possible to view white text and red borders that would later print as black text and red borders in a consumer market.

Typesetters had suffered with whatever was available for a long time and did not wait for WYSIWYG before using computer typesetting.

  • 1
    More to the point, white background was required during the time span between the emergence of WYSIWYG and the obsolecence of print. Commented Sep 18, 2018 at 19:29

Well, they weren't. Command-line interpreters typically dealt in characters - they'd send a character to the output device, and the output device displayed it. This might be an inky mark on paper, or a pattern of lit-up phosphor dots.

So it really turns into asking why the display component of a terminal is light-on-dark, and to my way of thinking, it's "obviously" because the screen is naturally dark. The hardware would light up some dots corresponding to the character being drawn.

The new-fangled VT100 did have a dark chars on light background mode, but to my eyes, it looked much less crisp.


I wanted to reinforce jcaron's excellent answer pointing to skeumorphism with its specific origin: the first commercial desktop system to offer a graphical interface was the Xerox Star, and its development and design were tightly focused around the desktop metaphor, from folders for directories to sheets of paper for documents themselves. Indeed, there's an argument to be made that it was so effective in that regard that it served to 'lock in' the dominant metaphor for interacting with digital data for a generation and more. Apple's decision to xerox the Star's UI for their Lisa and then Macintosh UIs brought the metaphor into public prominence, and then Microsoft's own cloning put it on every desktop, further reinforcing that paradigm. And of course, as noted text printed on paper is for numerous reasons almost entirely black on white, so using the same visual style in the desktop metaphor was the natural choice.

  • 2
    The Xerox Star didn't have draggable icons, pull-down menus or even resizeable windows. You'd never, ever mistake a Macintosh or a Lisa for one.
    – Tommy
    Commented Sep 19, 2018 at 3:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .