Error rgb()/rgba() color channel out of range
The valid ranges for red, green, blue, and alpha in rgb()/rgba() color values, and what happens when a channel value exceeds them.
The validator checks each channel inside a comma-separated rgb() or rgba() value: the red, green, and blue channels must fall within 0–255 (or 0%–100% if written as a percentage), and the alpha channel — the fourth argument in rgba() — must fall within 0–1 (or 0%–100%).
Example
/* Wrong: 300 is above the 0-255 range */
.banner { background: rgb(300, 0, 0); }
/* Wrong: alpha above 1 */
.banner { background: rgba(0, 0, 0, 1.5); }
/* Right */
.banner { background: rgb(255, 0, 0); }
.banner { background: rgba(0, 0, 0, 0.5); }Why it matters
Each of red, green, and blue represents one byte of color intensity, which is exactly why the valid range tops out at 255 — it's the largest value a single byte can hold. A value like 300 isn't a "very saturated" red; it's simply outside the format entirely. Browsers handle this by clamping the out-of-range value down to the nearest valid one (300 becomes 255), so the color often still renders — just not distinguishably different from what plain 255 would have produced, which masks the mistake. This usually comes from a manual typo, or from color values calculated programmatically (a lightening/darkening function, for instance) without clamping the result to the valid range before writing it out.
Frequently asked questions
Does an out-of-range value actually break the color, or just clamp it?
Browsers clamp out-of-range RGB and alpha values to the nearest valid boundary rather than rejecting the whole declaration, so the color usually still renders — just capped, which can look identical to the correct value at first glance and hide the underlying bug.
Does this check cover hsl() colors too?
Not currently — this check specifically covers the comma-separated rgb()/rgba() syntax, which is by far the most common way out-of-range values show up in hand-written or generated CSS.