Color Converter & Contrast Checker

Screens produce color by mixing light from red, green and blue subpixels at varying intensities — additive color mixing, where combining all three at full intensity produces white, unlike the subtractive mixing of paint. RGB values naturally range from 0 to 255 per channel because each channel is stored as one byte (8 bits, 2^8 = 256 possible values), which is also exactly why hex color codes use two hex digits per channel: each hex digit represents 4 bits, so two digits (00 to FF) cover the full 0-255 range in base 16.

That's the entire relationship between #RRGGBB and rgb(r, g, b): they're the same three numbers, just written in different bases. #ff9900 and rgb(255, 153, 0) describe the exact same color — hex is simply more compact for writing in CSS and design tools, while decimal RGB is often easier to reason about or manipulate programmatically.

RGB is how a screen produces color, but it's a genuinely awkward model for a human to reason about — there's no direct way to look at rgb(180, 60, 90) and know what that color looks like, or how to make it "a bit lighter" without recalculating all three channels. HSL (hue, saturation, lightness) and HSV/HSB (hue, saturation, value/brightness) both reorganize the same color space around how people actually think about color: hue as a position on a 360° color wheel, saturation as how vivid or muted a color is, and a third channel controlling how light or dark it is.

The practical difference between HSL and HSV is in that third channel: HSL's lightness runs from black, through the pure hue at 50%, to white at 100% — so a fully saturated color only looks 'pure' at the midpoint. HSV's value runs from black straight to the pure hue at 100%, with saturation separately controlling how much white gets mixed in — which is closer to how a physical paint-mixing metaphor (adding black, white or gray to a pure pigment) actually works, and why HSV shows up more often in color-picker UIs built around that mental model.

The contrast ratio between two colors isn't a simple difference of RGB values — it's computed from each color's relative luminance, a value from 0 (black) to 1 (white) derived from gamma-corrected RGB channels weighted to match human perceived brightness (green contributes far more to perceived brightness than blue, for instance). The contrast ratio formula is (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter color's luminance and L2 the darker one's — giving a ratio from 1:1 (identical colors, no contrast) up to 21:1 (pure black against pure white, the maximum possible).

WCAG 2.x defines four specific thresholds: AA requires at least 4.5:1 for normal text and 3:1 for large text (18pt+, or 14pt+ bold); AAA is stricter, requiring 7:1 for normal text and 4.5:1 for large text. "Large text" gets a lower bar because bigger glyphs remain legible at lower contrast than small ones do — the same contrast ratio that's perfectly readable at 24px can be genuinely hard to read at 12px.

Low-vision and color-vision-deficient users are the most direct beneficiaries of sufficient contrast, but the practical benefit is much broader: text with borderline contrast becomes hard to read on a cheap or poorly calibrated monitor, in bright sunlight on a phone screen, or simply for anyone tired at the end of a long day. Good contrast is one of the few accessibility properties that measurably helps every reader, not just the subset of users a compliance checklist is technically written for.

It's also one of the cheapest accessibility fixes available — unlike restructuring markup for screen readers or redesigning an interaction pattern for keyboard navigation, fixing a contrast failure is usually a one-line color change with zero impact on layout or functionality, which is exactly why it's worth checking early rather than discovering it in a late-stage audit.

Red-green color blindness is common enough that a meaningful share of any general audience will perceive certain hue pairs as far less distinct than someone with typical color vision does — which is exactly why accessibility guidance separately recommends never relying on color alone to convey information (a red vs. green status dot with no icon or label difference is a common failure mode). Sufficient contrast between the color and its background helps here too, since it keeps the shape and boundary of an element legible even when the specific hue is hard to distinguish.

The practical takeaway for interface work is to treat a contrast checker as a baseline check to run on every meaningful text/background pairing before shipping, not a one-time audit step — and to pair it with the separate habit of never using color as the only signal for state (error, success, disabled), since even perfect contrast doesn't fix a distinction that depends entirely on hue.