Typing <font color="chucknorris"> into an HTML document renders text in a dark red color — not because “chucknorris” is a secretly recognized color name, but because of a decades-old fallback algorithm browsers use to interpret invalid color values rather than simply rejecting them. This “legacy color parsing algorithm” tries to convert almost any string into something resembling a hex color code, no matter how nonsensical the input. The result for “chucknorris” happens to land on a reddish color, and the quirk has since become a well-known piece of web development trivia.
The Short Answer
When a browser encounters a color value it doesn’t recognize as a valid named color (like “red” or “blue”) or a properly formatted hex code, older HTML color-parsing rules don’t throw an error — instead, they attempt to strip out anything that isn’t a valid hexadecimal character, pad or trim the result to fit a standard format, and interpret whatever’s left as an RGB color. Because “chucknorris” happens to contain the letter “c” (a valid hexadecimal digit) among a string of otherwise invalid characters, it gets algorithmically transformed into the RGB value 192, 0, 0 — a dark red.
Walking Through the Actual Algorithm
The WHATWG HTML specification defines these exact steps for parsing a “legacy color value,” and running “chucknorris” through them produces a very specific, traceable result:
- Replace invalid characters with “0”. Only the digits 0-9 and letters a-f are valid hexadecimal characters. Going letter by letter through “chucknorris” (c-h-u-c-k-n-o-r-r-i-s), only the two “c” characters qualify as valid hex digits — everything else gets replaced with “0”, producing the string
c00c00000000 (after padding, explained next).
- Pad to a length divisible by three. The string needs to split evenly into three equal chunks representing red, green, and blue. “chucknorris” is 11 characters long, so a trailing “0” is added to make it 12.
- Split into three equal components. The 12-character string divides evenly into three 4-character chunks:
c00c, 0000, and 0000 — corresponding to red, green, and blue.
- Trim each component down to two characters. For components starting with “0,” leading zeros are stripped first; both
0000 chunks shrink down to 00. The c00c chunk doesn’t start with a zero, so instead its first two characters are simply kept: c0.
- Convert each two-character chunk to a decimal RGB value.
c0 in hexadecimal equals 192 in decimal. Both 00 chunks equal 0.
The final result: RGB(192, 0, 0) — a dark, brick-like red. This isn’t a coincidence or an Easter egg; it’s simply what happens when this specific string is fed through the standardized algorithm.
Why This Forgiving Behavior Exists at All
This algorithm traces back to HTML 4’s color and bgcolor attributes, and its leniency reflects a broader design philosophy in early web standards: browsers were built to degrade gracefully rather than break pages outright when developers made mistakes. Rather than rejecting an invalid color value and leaving an error or blank styling, the parser was designed to make its best attempt at producing some usable color, even from nonsensical input. This approach helped ensure that typos or malformed values in early, less-standardized web code wouldn’t cause visible failures.
Does This Still Work in Modern Browsers?
The color and bgcolor HTML attributes that make this trick work are technically obsolete, having been superseded by CSS — but they remain supported by browsers today for backward compatibility, and this legacy parsing behavior hasn’t been removed. Modern CSS itself has its own, separate form of lenient error handling: rather than rejecting invalid values outright, most browsers will clamp out-of-range numbers in functions like rgb() to the nearest valid value rather than fail. For example, rgb(300, -50, 1000) doesn’t throw an error — it gets clamped to rgb(255, 0, 255). The underlying principle is the same one that lets “chucknorris” render as red: the web’s long-standing preference for forgiving, best-effort parsing over strict rejection.
Join The Discussion
Quirks like the “chucknorris” color trick are a fun window into how much invisible, decades-old engineering keeps the modern web backward-compatible. Have you run into other strange legacy HTML or CSS parsing behaviors in your own projects? Share any browser quirks you’ve discovered, other strings that produce interesting colors, or your thoughts on how much of this old “forgiving” behavior should stick around in modern web standards.
