Color Brightness Calculator

Understanding the Color Brightness Calculator

A colour brightness calculator computes perceived luminance from RGB values and suggests whether dark or light text will read better on it. The weighting reflects a real property of human vision: the eye is far more sensitive to green than to blue.

How it actually works

Enter red, green, and blue values from 0 to 255. The calculator applies weights of 0.299 to red, 0.587 to green, and 0.114 to blue, sums them, and recommends dark text above a threshold of 128. RGB 120, 140, 160 gives a brightness of 136.3, hex #788CA0, and a recommendation for dark text.

The deeper context most people miss

These particular weights come from ITU-R Recommendation BT.601, developed for standard-definition television. HDTV and modern displays use BT.709, which weights green even more heavily at 0.7152 with red at 0.2126 and blue at 0.0722, so the same colour produces a slightly different brightness figure depending on which standard is applied.

Why perceived brightness is not the average of the channels

The human retina contains three types of cone cell with peak sensitivities in different parts of the spectrum, and they are not equally represented or equally sensitive. Sensitivity peaks in the green region around 555 nanometres in daylight vision, which is why green appears brightest for a given physical light intensity, and why safety equipment and high-visibility clothing frequently use yellow-green. Blue sensitivity is lowest, partly because blue-sensitive cones are far less numerous and are absent from the very centre of the fovea, which is why pure blue text on a black background looks dim and is hard to read at small sizes. The weights encode this so that a computed brightness figure corresponds roughly to what a person perceives rather than to the raw signal. There is a further subtlety that the simple weighted sum omits. Display output is not linear with the encoded value: an RGB value of 128 does not emit half the light of 255, because of gamma encoding, which allocates more of the available code values to darker tones where the eye is more discriminating. Properly computing relative luminance requires first linearising each channel by reversing the gamma encoding, then applying the weights. Formulas that skip this step, including the one used here, are quick approximations that work reasonably for many practical purposes and diverge from perceptual accuracy particularly for saturated colours and mid-tones.

A worked example: where the simple threshold fails

The calculation gives 136.3 for RGB 120, 140, 160, just above the 128 threshold, so it recommends dark text. That is probably right for this colour, and the threshold approach breaks down in predictable ways. Consider pure blue at RGB 0, 0, 255: the weighted sum gives 29.1, correctly indicating a dark background needing light text. Now consider pure yellow at 255, 255, 0: the sum is 226, correctly indicating light. But consider a saturated red at 255, 0, 0, which gives 76.2 and suggests light text, while a saturated green at 0, 255, 0 gives 149.7 and suggests dark. Both are reasonable. The failures appear near the threshold, where a colour computing 130 and one computing 126 receive opposite recommendations despite being visually almost identical, and where the actual readability depends on the specific text colour rather than a binary dark-or-light choice. This is why accessibility standards use contrast ratio between two specific colours rather than the brightness of one, since readability is a property of the pair. The Web Content Accessibility Guidelines specify a minimum contrast ratio of 4.5 to 1 for normal text and 3 to 1 for large text at level AA, rising to 7 to 1 and 4.5 to 1 at level AAA, computed from properly linearised relative luminance.

Deciding how to check contrast properly

For anything where readability matters, and particularly for anything public-facing, contrast ratio against the specific text colour is the measure to use rather than background brightness alone. The WCAG contrast formula computes relative luminance for both colours after linearising each channel, then takes the ratio of lighter plus 0.05 to darker plus 0.05, with the 0.05 accounting for ambient screen reflection. Numerous free tools compute this from two hex values, and browser developer tools now show contrast ratios directly when inspecting text. Meeting 4.5 to 1 for body text is a reasonable baseline and is a legal requirement in several jurisdictions for public sector and increasingly commercial sites, with accessibility legislation in the US, EU, and elsewhere referencing WCAG. Several specific traps recur. Light grey text on white, common in modern design, frequently fails badly despite looking clean to designers with good vision on good monitors. Text over photographic backgrounds varies in contrast across the image and needs either an overlay or a solid backing. Placeholder text in form fields is frequently too light. Disabled state styling is exempt from contrast requirements but should still be distinguishable. And colour alone should never convey information, since colour vision deficiency affects a meaningful proportion of the population, most commonly red-green.

Colour spaces, and why hex values are less absolute than they look

A hex value specifies a colour within a colour space, and without knowing the space it does not fully determine what is displayed. Standard RGB, or sRGB, has been the default for the web and most consumer displays for decades, and most hex values are implicitly sRGB. Wider gamut spaces including Display P3, used by many recent Apple devices, and Adobe RGB, common in print workflows, can represent more saturated colours, so the same numerical values map to different physical colours in each. This is why an image can look different across devices, and why colour management, where profiles describe how to map between spaces, exists. Modern CSS supports specifying colours in other spaces explicitly, which matters for design systems targeting wide-gamut displays. Beyond gamut, perceptual uniformity is a separate issue: equal numerical steps in RGB do not correspond to equal perceived differences, which makes RGB poor for tasks including generating colour scales and interpolating gradients. Perceptually uniform spaces including CIELAB, and more recently OKLab and OKLCH which are supported in modern CSS, address this and produce noticeably better gradients and more evenly spaced palettes. For anyone building a design system, working in a perceptual space and converting to sRGB for output generally produces better results than manipulating hex values directly.

Variations: luminance formulas, contrast checking, and colour blindness

Several brightness formulas circulate. The BT.601 weights used here suit standard-definition video and remain widely used in quick calculations. BT.709 weights, at 0.2126 red, 0.7152 green, and 0.0722 blue, apply to HD video and are used in the WCAG relative luminance formula after linearisation. A simple average of the three channels is sometimes seen and is perceptually poor. The HSP formula uses a square root of weighted squares and claims better perceptual correspondence. For contrast specifically, the WCAG ratio is the standard for accessibility compliance, though it has documented weaknesses particularly with dark backgrounds and with certain colour pairs, and the APCA algorithm has been developed as a candidate replacement with better perceptual grounding, appearing in draft WCAG 3 work. For colour vision deficiency, simulation tools show how a palette appears under the common types, and designing so that information is conveyed by more than hue alone addresses it more robustly than any specific palette choice.

Choosing readable colour combinations

Use contrast ratio between the specific text and background colours rather than background brightness alone, since readability is a property of the pair and a threshold on one colour cannot capture it. Meet at least 4.5 to 1 for body text and 3 to 1 for large text, which is the WCAG AA standard and a legal requirement in several jurisdictions. Check with a tool rather than by eye, since designers with good vision on good monitors routinely ship light grey on white that fails badly. Add an overlay or solid backing behind text over photographic backgrounds, where contrast varies across the image. Never convey information by colour alone, since colour vision deficiency affects a meaningful proportion of people. Use a perceptually uniform colour space such as OKLCH for generating scales and gradients, since equal RGB steps do not produce equal perceived differences. And be aware that hex values are space-dependent, so the same values render differently on wide-gamut displays.

What people get wrong

• Using background brightness alone to decide text colour, when readability depends on the contrast ratio between the specific pair of colours.
• Averaging the three channels for brightness, which ignores that the eye is roughly five times more sensitive to green than to blue.
• Judging contrast by eye on a good monitor, which routinely produces light grey on white that fails accessibility standards for many users.
• Interpolating gradients or generating scales in RGB, where equal numerical steps do not correspond to equal perceived differences.

Where the math comes from

Brightness = 0.299 × Red + 0.587 × Green + 0.114 × Blue, using ITU-R BT.601 luma coefficients, with a recommendation for dark text above a threshold of 128. These weights reflect that human vision is most sensitive to green and least to blue. Note this omits gamma linearisation, so it approximates rather than computes true relative luminance; the WCAG formula linearises each channel before weighting.

Questions and answers

Related calculators

Social Media Post Scheduler · Battery mAh · Shoe Size Converter · Carbon Footprint · Typing Speed