> Who in the rainbow can draw the line where the violet tint ends and the orange tint begins? Distinctly we see the difference of the colors, but where exactly does the one first blendingly enter into the other? So with sanity and insanity. > —Herman Melville, _Billy Budd_ > Orange, red? I don’t know what to believe anymore! > —Anonymous, Color Survey > I WILL EAT YOUR HEART WITH A FUCKING SPOON IF YOU AKS ANY MORE QUESTIONS ABOUT COLORS > —Anonymous, Color Survey Thank you so much for all the help on the color survey. Over five million colors were named across 222,500 user sessions. If you never got around to taking it, it’s too late to contribute any data, but if you want you can see how it worked and take it for fun here. First, a few basic discoveries: * If you ask people to name colors long enough, they go totally crazy. * “Puke” and “vomit” are totally real colors. * Colorblind people are more likely than non-colorblind people to type “fuck this” (or some variant) and quit in frustration. * Indigo was totally just added to the rainbow so it would have 7 colors and make that “ROY G. BIV” acronym work, just like you always suspected. It should really be ROY GBP, with maybe a C or T thrown in there between G and B depending on how the spectrum was converted to RGB. * A couple dozen people embedded SQL ‘drop table’ statements in the color names. Nice try, kids. * _Nobody_ can spell “fuchsia”. Overall, the results were really cool and a lot of fun to analyze. There are some basic limitations of this survey, which are discussed toward the bottom of this post. But the sheer amount of data here is cool. **Sex** By a strange coincidence, the same night I first made the color survey public, the webcomic Doghouse Diaries put up this comic (which I altered slightly to fit in this blog, click for original): It was funny, but I realized I could test whether it was accurate (as far as chromosomal sex goes, anyway, which we asked about because it’s tied to colorblindness) _[Note: For more on this distinction, see my_ _follow-up post_ _]_. After the survey closed, I generated a version of the Doghouse Diaries comic with actual data, using the most frequent color name for the handful of colors in the survey closest to the ones in the comic: Basically, women were slightly more liberal with the modifiers, but otherwise they generally agreed (and some of the differences may be sampling noise). The results were similar across the survey—men and women tended on average to call colors the same names. So I was feeling pretty good about equality. Then I decided to calculate the ‘most masculine’ and ‘most feminine’ colors. I was looking for the color names most disproportionately popular among each group; that is, the names that the most women came up with compared to the fewest men (or vice versa). Here are the color names most disproportionately popular among women: 1. Dusty Teal 2. Blush Pink 3. Dusty Lavender 4. Butter Yellow 5. Dusky Rose Okay, pretty flowery, certainly. Kind of an incense-bomb-set-off-in-a-Bed-Bath-&-Beyond vibe. Well, let’s take a look at the other list. Here are the color names most disproportionately popular among men: 1. Penis 2. Gay 3. WTF 4. Dunno 5. Baige I … that’s not my typo in #5—t _he only actual color_ in the list really is a misspelling of “beige”. And keep in mind, this is based on the number of unique people who answered the color, not the number of times they typed it. This isn’t just the effect of a couple spammers. In fact, this is _after_ the spamfilter. I weep for my gender. But, on to: **RGB Values** Here are RGB values for the first 48 out of about a thousand colors whose RGB values (across the average monitor, shown on a white background) I was able to pin down with a fairly high degree of precision: The full table of 954 colors is here, also available as a text file here (I have no opinion about whether it should be used to build a new X11 rgb.txt except that seems like the transition would be a huge headache.) The RGB value for a name is based on the location in the RGB color space where there was the highest frequency of responses choosing that name. This was tricky to calculate. I tried simple geometric means (conceptually flawed), a brute force survey of all potential center points (too slow), and fitting kernel density functions (math is hard). In the end, I used the average of a bunch of runs of a stochastic hillclimbing algorithm. For mostly boring notes on my data handling for this list, see the comments at the bottom of the xkcd.com/color/rgb/ page. **Spelling and Spam** Spelling was an issue for a lot of users: Now, you may notice that the correct spelling is missing. This is because I can’t spell it either, and when running the analysis, used Google’s suggestion feature as a spellchecker: A friend pointed out that to spell it right, you can think of it as “fuck-sia” (“fuch-sia”). Misspellings aside, a lot of people spammed the database, but there were some decent filters in place. I dropped out people who gave too many answers which weren’t colors used by many other people. I also looked at the variation in hue; if people gave the same answer repeatedly for colors of wildly varying hue, I threw out all their results. This mainly caught people who typed the same thing over and over. Some were obviously using scripts; based on the filter’s certainty, the #1 spammer in the database was someone who named 2,400 colors—all with the same racial slur. **Map** Here’s a map of color boundaries for a particular part of the RGB cube. The data here comes from a portion of the survey (1.5 million results) which sampled only this region and showed the colors against both black and white backgrounds. The data for this chart is here (3.6 MB text file with each RGB triplet named). Despite some requests, I’m not planning to make a poster of any of this, since it seems wrong to take advantage of all this volunteer effort for a profit; I just wanted to see what the results looked like. You’re welcome to print one up yourself (huge copy here), but keep in mind that print color spaces are different from monitor ones. **Basic Issues** Of course, there are basic issues with this color survey. People are primed by the colors they saw previously, which adds overall noise and some biases to the data (although it all seemed to even out in the end). Moreover, monitors vary; RGB is not an absolute color space. Fortunately, what I’m really interested in is what colors will look like on a typical monitors, so most of this data is across the sample of all non-colorblind users on all types of monitors (>90% LCD, roughly 6% CRT). Color is a really fascinating topic, especially since we’re taught so many different and often contradictory ideas about rainbows, different primary colors, and frequencies of light. If you want to understand it better, you might try the neat introduction in Chapter 35 ofThe Feynman Lectures on Physics (Vol. 1), read Charles Poynton’s Color FAQ, or just peruse links from the Wikipedia article on color. For the purposes of this survey, we’re working inside the RGB space of the average monitor, so this data is useful for picking and naming screen colors. And really, if you’re reading this blog, odds are you probably—like me—spend more time looking at a monitor than at the outdoors anyway. **Miscellaneous** Lastly, here are some assorted things people came up with while labeling colors: Thank you so much to relsqui for writing the survey frontend, and to everyone else who sacrificed their eyeballs for this project. If you have ideas and want to analyze these results further, I’ve posted the raw data as an SQLite dump here (84 MB .tar.gz file). It’s been anonymized, with IPs, URLs, and emails removed. I also have GeoIP information; if you’d like to do geocorrelation of some kind, I’ll be providing a version of the data with basic region-level lat/long information (limited to protect privacy) sometime in the next few days. _Note: The ColorDB data is the main survey. The SatOnly data is the supplementary survey covering only the RGB faces in the map, and was presented on a half-black half-white background.)_ And, of course, if you do anything fun with this data, I’d love to see the results—let me know at xkcd@xkcd.com. ### Share this: * Click to share on X (Opens in new window) X * Click to share on Facebook (Opens in new window) Facebook * Like Loading... ### _Related_

curl supports getting built with _eleven_ different TLS libraries. Six of these libraries are OpenSSL or forks of OpenSSL. Allow me to give you a glimpse of their differences, similarities and some insights into what it takes to support them all. ## SSLeay It all started with SSLeay. This was the first SSL library I found out to exist and we added the first HTTPS support to curl using this library in the spring of 1998. Apparently the SSLeay project was started already back in 1995. This was back in the days we still only had SSL; TLS would come later. ## OpenSSL This project was created (forked) from the ashes of SSLeay in late 1998 and curl supported it already from its start. SSLeay was abandoned. OpenSSL always had a quirky, inconsistent and extremely large API set (a good chunk of that was inherited from SSLeay), that is further complicated by documentation that is sparse at best and leaves a lot to the users’ imagination and skill to dig through source code to get the last details answered (still today in 2025). In curl we keep getting occasional problems reported with how we use this library even decades in. Presumably this is the same for every OpenSSL user out there. The OpenSSL project is often criticized for having dropped the ball on performance since they went to version 3 a few years back. They have also been slow and/or unwilling at adopt new TLS technologies like for QUIC and ECH. In spite of all this, OpenSSL has become a dominant TLS library especially in Open Source. ## LibreSSL Back in the days of Heartbleed, the LibreSSL forked off and became its own. They trimmed off things they think didn’t belong in the library, they created their own TLS library API and a few years in, Apple ships curl on macOS using LibreSSL. They have some local patches on their build to make it behave differently than others. LibreSSL was late to offer QUIC, they don’t support SSLKEYLOGFILE, ECH and generally seem to be even slower than OpenSSL to implement new things these days. curl has worked perfectly with LibreSSL since it was created. ## BoringSSL Forked off by Google in the Heartbleed days. _Done by Google for Google_ without any public releases they have cleaned up the prototypes and variable types a lot, and were leading the QUIC API push. In general, most new TLS inventions have since been implemented and supported by BoringSSL before the other forks. Google uses this in Android in other places. curl has worked perfectly with BoringSSL since it was created. ## AmiSSL A fork or _flavor_ of OpenSSL done for the sole purpose of making it build and run properly on AmigaOS. I don’t know much about it but included it here for completeness. It seems to be more or less a port of OpenSSL for Amiga. curl works with AmiSSL when built for AmigaOS. ## QuicTLS As OpenSSL dragged their feet and refused to provide the QUIC API the other forks did back in the early 2020s (for reasons I have yet to see anyone explain), Microsoft and Akamai forked OpenSSL and produced _QuicTLS_ which has since tried to be a _light-weight_ fork that mostly just adds the QUIC API in the same style BoringSSL and LibreSSL support. _Light-weight_ in the meaning that they were tracking upstream closely and did not intend to deviate from that in other ways than the QUIC API. With OpenSSL3.5 they finally shipped a QUIC API that is different than the QUIC API the forks (including QuicTLS) provide. I believe this triggered QuicTLS to reconsider their direction going forward but we are still waiting to see exactly how. curl has worked perfectly with QuicTLS since it was created. ## AWS-LC This is a fork off BoringSSL maintained by Amazon. As opposed to BoringSSL, they do actual (frequent) releases and therefore seem like a project even non-Amazon users could actually use and rely on – even though their stated purpose for existing is _to maintain a secure libcrypto that is compatible with software and applications used at AWS_. Strikingly, they maintain more than “just” libcrypto though. This fork has shown a lot of activity recently, even in the core parts. Benchmarks done by the HAProxy team in May 2025 shows that AWS-LC outperforms OpenSSL significantly. The API AWS-LC offers is not identical to BoringSSL’s. curl works perfectly with AWS-LC since early 2023. ## Family Tree The OpenSSL fork family tree ## The family life Each of these six different forks has its own specifics, APIs and features that also change and varies over their different versions. We remain supporting these six forks for now as people still seem to use them and maintenance is manageable. We support all of them using the same single source code with an ever-growing #ifdef maze, and we verify builds using the forks in CI – albeit only with a limited set of recent versions. Over time, the forks seem to be slowly drifting apart more and more. I don’t think it has yet become a concern, but we are of course monitoring the situation and might at some point have to do some internal refactors to cater for this. ## Future I can’t foresee what is going to happen. If history is a lesson, we seem to rather go towards _more_ forks rather than _fewer_ , but every reader of this blog post of course now ponders over how much duplicated efforts are spent on all these forks and the implied inefficiencies of that. On the libraries themselves but also on users such as curl. I suppose we just have to wait and see.