Death of the Websafe Color Palette?
by David Lehn and Hadley Stern

One of the givens of Web design, the holiest of holy truths, is the sanctity of the 216 websafe color palette. It's a rite of initiation for every Web designer or developer: Use only these colors, we are told, and don't question why.

But it's been more than three years since Lynda Weinman assembled her "browser safe palette" for Photoshop, and a lot has changed in the world of Web design since then. Designers have kept up with changes in client-side technologies, such as dHTML and Flash, and we've given up font tags in favor of CSS styles, tables for divs. Yet we cling to the 216 websafe color palette even though it continues to be the bane of a Web designer's existence.

Just recently, the two of us found ourselves caught up in the rhetoric of websafe yet again. Our project featured a design with beautiful, subtle pastel colors that looked ridiculous when converted to their nearest websafe colors. This time, however, we refused to capitulate to the god of websafe. Wasn't there a way out of this ancient palette's confines? We decided it was high time we found out. Our investigation began with a series of questions:

  1. Given all the new versions of browsers and operating systems that have emerged since the original websafe palette was created, is the websafe palette still Web-safe?
  2. With the dominant number of users now running High Color and True Color displays -- as opposed to the 256 color displays of three or four years ago -- can we use whatever colors we want?
  3. And if it turns out that our choice of colors is still limited, is there a new websafe palette for High and True Color machines?

As with anything to do with the Web, the answers we discovered weren't simple. There are pros and cons to weigh, twisted plots to unravel, and some explaining to do with each of these questions. Certainly they deserve a closer look. So we'll start with a refresher on why the websafe palette was needed in the first place. Then we'll try to figure out how operating systems display color on High Color and True Color systems. Next, we'll discuss what happens when things go wrong.

Since these three sections are a bit technical, you might want to skip ahead for the all important test results, along with some strategies to help you through the deep, dark night.

For for those of you willing to wade through all the techie bits, we'll begin with a look at the reasons for using the websafe palette in an 8-bit world. Before we proceed, however, we would like to thank Microsoft's Robert Hess for his generous and intelligent help. (See! Microsoft is not all evil!)

OK, let's get started.

Why the Websafe Palette?

Some of you young'uns may not remember, but back in the early days of the Web, there was no such thing as a rollover. There was no Flash. And we only had 256 colors.

Three or four years ago, most personal computers supported a color depth of, at best, 8 bits. What does that mean, you ask? The digital display of color tends to be divided into three root colors: red, green, and blue (i.e., RGB). The pixels in your screen then give different intensities to each of these root colors to produce all the other colors. The intensity for each root color is broken into even units, not because it looks better but because computers like things that way. Currently, and for some time now, that scale has had 256 values. If you start at 0, your scale stops at 255. (This should all be starting to look familiar to anyone who's used Photoshop.) So, if we have 256 possible values for each of our root colors, that gives a total of 16,777,216 colors (256 * 256 * 256), a.k.a. "millions of colors," "True Color," or "24-bit color."

Those old personal computers didn't have a lot of video memory or very sophisticated video cards, so they could only support a total of 256 colors at a time (out of a possible 16,777,216). 256 color support, or color "depth," is also known as 8-bit color because it is 2 raised to the power of 8 (2 being the basic unit that computers use to store information -- a single bit). The questions then are which 256, and why?

As we said, computers like mathematical simplicity, so the palette has to have consistent spacing. We need to find the largest number that can be cubed (to accommodate the three root colors RGB) without its cubed value exceeding 256. That number is 6 (6 * 6 * 6 = 216). If you need six points on a scale, you need five spaces. Since we started our scale on 0, not 1, we can divide 255 by 5 and get the result of 51. Therefore, our values are 0, 51, 102, 153, 204, and 255. Any combination of these in the R, G, or B positions results in a valid color for an 8-bit display.

Note that color values may also be given in "hexadecimal" form. For example, the decimal value triad 51-204-102 would be 33CC66 in hex. There's nothing magical going on here -- it's just a simple conversion from base-10 to base-16. Photoshop 5.5 now does this for you, but you can do it yourself if you really, really want to.

In theory, an operating system can display any 256 colors, but your machine would take a real performance hit if it had to redraw its palette every time you toggled between applications. Instead, Web browsers convert all colors to static, generic palettes. This gives consistency, which improves performance. The 216 colors we found above are part of the generic palette for both Internet Explorer and Netscape Navigator. You may have noticed, though, that we have 40 colors unaccounted for. About 20 of those colors are fixed by the operating system itself. Windows and Macintosh, however, don't choose the same set of colors for their system palettes (here, take a look). In order to attain cross-operating system consistency, we eliminate both their system palettes from our design palette. Then there are a few stragglers, which are cut out for simplicity's sake. So, we're back to the evenly spaced 216 colors we got earlier. And that is the websafe -- or rather, the cross-Netscape Navigator-Internet Explorer-Windows-MacIntosh-8-bit -- palette.

Now, what about higher color depths? Well, hang on to your Visibone websafe mousepads, and let's take a look.

High and True Color

At higher bit depths, the fixity of the color palette goes out the window. Generally there are three other bit depths to consider: 15-bit, 16-bit, and 24-bit. 15- and 16-bit depths are known as "thousands of colors" or High Color. 24-bit is known as "millions of colors" or True Color. (There's also 32-bit depth, but that merely helps the system render colors more quickly, not render more colors; it still only displays 24 bits of colors.) Think of these palettes as adaptive: They adjust to whatever colors are requested.

True color is nice and simple. If your machine is running at 24-bit depth, it can display 16,777,216 colors, which is convenient since that's also the number of all the possible colors (as we calculated before).

High Color, on the other hand, is a minefield. Understanding why it's so difficult can be pretty hairy, mathematically speaking, but bear with us because it's important.

If you go through the same math we performed earlier to find the evenly spaced intervals on the scale, you'll discover that all the values work out to fractional values on the 24-bit scale.

To make things easier, let's put aside the conventional RGB values and instead focus on percentages. If you give R a value of 51, you're giving it 20 percent of its full intensity (51/255). Give G 146, and it's 57.25 percent of its full intensity (146/255). In fact, each time you increase the value by 1, you increase the percentage by 0.39216 percent (1/255). 24-bit color gives you 8 bits of color on each root color (R,G,B). 8 bits of color, in case you've forgotten, gives us 256 colors. If you set 0 = 0 percent and 255 = 100 percent, then you get percentages that match up with those we just got above.

If, however, you distribute 15- and 16-bit color evenly across the root colors, you get 5 or 6 bits of color for the R, G, and B positions. 15-bit would have a 5 x 5 x 5 distribution, and 16-bit would have 5 x 6 x 5. 5 bits of color yields 32 colors, and 6 bits yields 64. Set 0 = 0 percent and 31 = 100 percent. An increment in value of 1 on the 5-bit scale, then, would amount to 3.2258 percent. Now set 0 = 0 percent and 63 = 100 percent. An increment in value of 1 on the 6-bit scale would amount to 1.5873 percent. So, the smallest step on the 24-bit scale does not equal the smallest steps on the 15- and 16-bit scales. Moreover, the smallest step on the 24-bit scale (0.39216 percent) does not divide evenly into any of the values on the 15- and 16-bit scales -- well, there are two exceptions: black (0 percent) and white (100 percent). Other than those two, no colors are shared by the 8-/24-bit scale on the one side and the 15- and 16-bit scales on the other.

In other words: There are no shared colors between high color (15- or 16-bit) and true color (24-bit) depths. 24-bit is the full palette, and this is the palette we use with design programs such as Photoshop. 8-bit is a subset of that 24-bit palette. The old 216-websafe palette is a subset of the 8-bit palette, identified for browser and operating system compatibility. But the 15-bit and 16-bit palettes are not subsets of the 24-bit palette; they are entirely distinct palettes. So no matter which color you choose when you're designing (excluding black and white), you cannot choose a color that exists both in the 24-bit palette and in either the 15- or 16-bit palettes.

Now that we understand the mechanics of color in varying bit-depths, the next critical question we need to answer is what happens when a browser comes across a color outside of the supported palette.

Unsupported Colors

When the browser receives a request for a color it doesn't support, it has two ways to deal with the problem: It can either transform the requested color into a color it does support (ideally it will select the nearest color, though, as you will see, that isn't always the case). Or it can dither the color. This means that it will attempt to approximate the requested color by combining two colors it does support. To do this, it creates an overlapping lattice, which looks like this


Not a pretty sight, indeed. If this problem occurs in a dense image, like a JPEG, it's often acceptable, since the color variations are subtle. But if it happens in an area of "flat" (solid) color, it can look quite hideous (as you can see above). Flat color is usually created by code (as in a table cell's BGCOLOR attribute) or with a GIF.

The old 216 websafe palette was identified because it offered a palette that was stable across all browsers and operating systems when running at 8-bit color depth, and so the designer could rest assured that the colors wouldn't dither. High Color systems are substantially better than 8-bit systems. In particular, they tend not to really dither colors. Instead, the application -- for our purposes, the browser -- performs a call to the operating system that returns a new color. As we just concluded, High Color systems share no colors with your standard Photoshop 24-bit color palette (except for black and white). Consequently, browsers running on High Color systems have to perform this request for a new color continually. Since High Color is still a good color depth, the colors that the system chooses are usually good (solid, true colors), but they're not exactly what you thought you were getting when you originally selected the colors for your site.

OK, now that we have the groundwork in place, let's move on to our tests.

The Colors Formerly Known as Websafe

To see how all this technical theory plays out in practice, we performed a series of tests with our eyes on how the old 216 websafe palette actually fares on newer machines. We started by creating a test page with all 216 colors. We placed a 60 x 60 GIF in the center of a table cell with CELLPADDING=10 and BGCOLOR set to the same HEX value as the GIF. What we're hoping for is that the little square GIF in the center will be identical to the color of the cell. If we can see the square -- even in the slightest degree -- it means that something went wrong.

We did a spot-check of the websafe palette test page on a 24-bit system and, as expected, it displayed the colors perfectly: No little boxes peeped through. The real challenge would be on 8-bit and High Color systems.

We should note here that for us, High Color on Windows (95/98) was 16-bit, as a 15-bit machine proved exceedingly difficult to locate. Systems rarely offer 15-bit depth, and so we weren't too disturbed by our lack of testing on it, but if you would like to fill in that gap, please do so and send us your results. High Color on Macintosh is identified only as "thousands of colors," so we can't tell you whether it's 15-bit or 16-bit. But whichever it is, that's the only choice there is for the Mac, so the other depth is moot.

We then looked at the 216 websafe palette on the following browsers:

Results at 8-bit

The results when running our machines at 8-bit (256) color were almost reassuring. All browsers on Macintosh handled the colors exactly as they are supposed to, as did Netscape on Windows. But Internet Explorer for Windows, it turns out, has a bug. (As a result of this research, Microsoft is now aware of the bug and will fix it, hopefully in the next release of Internet Explorer. There wasn't enough time to fix it in the 5.5 release, unfortunately.) When the websafe palette was first assembled, only Internet Explorer 3 existed. Since then, the method the browser uses to display colors has changed. As a result, four colors from the old websafe palette cannot be considered websafe anymore. Those colors are 00FF33, 33FF00, 0033FF, 3300FF -- two greens and two blues. When viewed at 8-bit on Windows in Internet Explorer v4-5.5, these colors will not be rendered consistently across GIF and BGCOLOR. (To see the discontinuity, drop your machine's depth to 8-bit, reboot, and then take a look at our test. Remember, you will see this problem only if you are running IE4.x or higher on Windows.) Admittedly this is a problem only when viewed at 8-bit depth, but that was precisely the color depth the websafe palette was designed to accommodate. So now our websafe palette is now down to 212 colors.

Results at 16-bit

When we viewed the old 216 websafe color palette at 16-bit depth, we were shocked. All over the place there were little squares amid our blocks of color. Sometimes they were blaringly obvious; other times, nothing more than timid ghosts of color. But either way, we could definitely see the GIF inside the table cell. This didn't happen in all browsers. Internet Explorer 5 on both Windows and Macintosh handled the colors properly, as did Netscape 4.6 (tested only on Macintosh) and 3.04 (tested only on Windows). But all the other browsers we tested ran into problems ... lots of problems. To make matters worse, the problem colors weren't the same for each of these browsers. For instance, #336633 failed in Internet Explorer 4 on Windows and 4.5 on Macintosh, while it was fine on Netscape 4.07 and 4.74 on Windows. Then a color like #FF99CC worked fine in all the Internet Explorers but failed in Netscape 4.07 and 4.74 on Windows.

When we say the color "failed," what we mean is that the browser shifted the color requested by the image (GIF) and by the BGCOLOR (hex value), but it didn't shift them to the same value. The browsers tend to get confused. Which is closer to 2: 1.9 or 2.1? It's really a toss-up, right? The browsers that had problems with displaying color at 16-bit color depth tried to, as it were, choose both 1.9 and 2.1 simultaneously. But by shifting the GIF to one value and the BGCOLOR to another, the browsers created a discontinuity in the color. It's not as bad a sight as a full-blown dither, but it's potentially jarring nevertheless. (For the record: As far as we can tell, it is indeed a bug that GIFs and code-generated color do not always get shifted to the same value at High Color depths. There doesn't seem to be a technical reason for this, since some of the browsers we looked at handled the situation perfectly fine.)

After the pixeldust settled, we looked at what was left of the ersatz websafe palette. There wasn't much. Admittedly, we got different results in what would seem to be the same conditions: one Win9x machine would fail for a color, and another such machine wouldn't. We decided to play it safe. Really safe. We found that only 22 of the 216 colors we began with did not end up being shifted incorrectly in at least one viewing environment. So, it looks like we have roughly 22 colors that are really websafe -- Windows and MacIntosh, Internet Explorer and Netscape Navigator, 8-bit, 16-bit, and 24-bit compatible for GIFs and BGCOLOR. We call this the The Reallysafe Palette (hope you like green ...).

Before we finish, we want to offer you some strategies to help you deal with this "terrible 22" news, and also to ask for help from those who can to save us all from our interminable despair.

Coping in an Unwebsafe World

The first thing you need to do when choosing colors is identify, with as much precision as possible, the distribution of technologies of your audience. The most recent numbers we've seen from StatMarket put True Color (24- and 32-bit) at about 38 percent of users; High Color (16-bit) at about 56 percent; and 256-color users are at about 6 percent. You might feel relieved by these numbers, since so few are at 256 color depth, but don't be: Unless you work entirely in black and white, approximately half your general audience won't properly see the colors you select for your site.

Once you've got the distribution of your audience identified, you have a basis to choose a strategy. Here's a handful of suggestions to get you started:

STRATEGY 1 -- Use the reallysafe palette.
We know it's not pretty, we know it's only 22 colors, but it does give you reliable control over the colors your users see.

STRATEGY 2 -- Don't sweat it.
You're always free to run roughshod over your audience as you indulge your hearty designer appetite. But we find this a slightly unsatisfying, not to mention unprofessional, approach.

STRATEGY 3 -- Ignore 16-bit users.
If you do this, you'll regain the use of most of the old websafe palette (minus the four colors that we discovered don't work in Internet Explorer on Windows). It's a solution you can live with, except that it favors the lowest-tech 6 percent slice over the higher-tech 56 percent slice. We don't usually agree with such an approach, but in this case you could argue that the colors an 8-bit user sees when fed an unsupported color (a hideous dither) is much worse than what a 16-bit user sees (a slight shift in the color).

STRATEGY 4 -- Ignore 8-bit users.
This approach favors the group that most likely constitutes the majority of your users, but it can give the 8-bit users a rough ride. You will get the same kinds of problems you got when looking at the old 216 websafe palette on a 16-bit system: GIFs and code-generated color will shift all too regularly to inconsistent values. So when you design a site, your chosen palette will have to be tested on a whole bunch of browsers and operating system environments (congratulations, you're now in the same boat as the developers who have to test their dHTML across myriad environments, only you can't even write an API).

The only consolation we can offer you here is this tool, which will at least make it a little easier to set up your color tests. We should warn you, though, that you're unlikely to find a set of colors that works correctly across all the environments you're targeting. We tried a few dozen colors and weren't very successful at finding palettes that worked properly. You'll probably find that once you've chosen your palette and tested it in the relevant environments, you have to go through several ever-so-slight tweaks of a color before you get it to be consistent across the relevant environments. You might try to change the value of one root color by just 1 increment (e.g., change AC to AD, or 09 to 08). Unfortunately, some colors will never be satisfactory, so you'll either have to ax them altogether or opt to let the colors shift as they may for the users of the offending environments.

STRATEGY 5 -- Keep the GIFs and code-generated color separated.
Since the shifts in color performed by the browser on 16-bit systems are usually very subtle, they won't cause a drastic imbalance in your chosen palette for the most part. But if you place a GIF and code-generated color right next to each other, the browser's bad habit of shifting the two to different values gets highlighted, and the discontinuity suddenly gets thrown into relief. If you keep the two apart, however, users will be less likely to notice the problem. (Although you should still test your colors; some differences are too distinct to ignore, no matter how far apart they are).

STRATEGY 6 -- Use transparent backgrounds.
If you do have to have a GIF and code-generated color next to each other, try this: When you export your GIF, select the color that's going to be in the code next to it and make that transparent. Then set the BGCOLOR of both the cell in which you've placed the GIF and the adjacent cell to the same value. That color will now bleed through the GIF, and regardless of which color the browser shifts it to, it will be the same for both the GIF and the code-generated color, since really it's not in the GIF at all. There is, however, at least one big limitation with this approach: You can only choose one color to be transparent in the GIF, which is a problem if the GIF has to be continuous with more than one color. To be sure, you can make more than one color in a GIF be transparent, but the color that will bleed through will have to be the BGCOLOR of an HTML container (such as a DIV, SPAN, or TD), and an image can't span these containers. Therefore, no matter how many colors you make transparent in your GIF, only one color can show through.

STRATEGY 7 -- Use Flash.
Flash's colors get drawn by its proprietary plug-in, not by the browser, so there's no "GIF versus code-generated color" issue here. The colors you select will still shift when viewed in a High Color system, but the discontinuity between the way GIFs and code-generated color shift will be eliminated. Of course, Flash has myriad problems of its own, which we'll leave to you to assess.

STRATEGY 8 -- Help us!
We certainly don't know all there is to know about hardware or software. We haven't managed to test all colors on all browsers and all platforms, so our results aren't exhaustive and complete. Most importantly, we don't have the power to make the browser flaws go away. You can help us with all these shortcomings. First, you can validate our results. Second, you can try to help us piece together a palette of colors that is stable (no discontinuous shifting) on High Color systems across all common browser and operating system environments. And third, if you work at Netscape, you might look into fixing this problem for the next and all subsequent releases of your browsers. We found Microsoft to be very responsive to our inquiries, and fixes for these bugs are forthcoming. Sadly (and not to slam anyone), we weren't as successful with Netscape. If you can offer us insight into current versions of Netscape to create a temporary fix, that's great. And if you can ensure that future releases of it avoid these problems altogether, that's even better. In any case, let us know what you discover.

STRATEGY 9 -- Go back to print design.

David Lehn and Hadley Stern have on occasion been called obsessive. David is a senior information architect and interface developer in the Milan office of Razorfish. Hadley is a senior designer in Razorfish's Boston office.


Feedback  |  Help  |  About Us  |  Jobs  |  Advertise  |  Privacy Statement  |  Terms of Service

Copyright © 1994-2000 Wired Digital Inc., a Lycos Network site. All rights reserved.