Hex Color Tools Calculator

Understanding the Hex Color Tools Calculator

A hex colour tool converts a code to RGB and derives its brightness, a recommended text colour, and its complement. The text recommendation is the useful output, and the method it uses is a simplification of what accessibility standards actually require.

How it actually works

Enter a hex colour. The calculator converts to RGB, computes a weighted brightness, recommends black or white text, and inverts each channel for the complement. The value 3B82F6 gives 48% brightness with white text recommended.

The deeper context most people miss

Green contributes over half the perceived brightness and blue barely a tenth, because the eye's cone response peaks in the green region. Averaging the three channels equally, which looks reasonable, produces a brightness figure that disagrees noticeably with what people see.

Why the accessible contrast calculation is more involved

The weighted brightness used here is a serviceable approximation and is not what the Web Content Accessibility Guidelines specify. The standard computes relative luminance by first linearising each channel, undoing the sRGB transfer function, then applying weights of roughly 0.2126, 0.7152, and 0.0722, and finally taking a ratio between the lighter and darker colours with a small offset. That ratio must reach 4.5 to 1 for normal text at the AA level and 3 to 1 for large text, rising to 7 to 1 at AAA. The linearisation step is what the simple weighted average omits, and it matters because the encoded values are not proportional to light, so mid-tones are systematically misjudged without it. That is why a simple brightness threshold sometimes recommends text that fails an actual contrast check, particularly on mid-range colours where the decision is closest. The standard itself has known limitations: it treats all colours of equal luminance as equally readable when perceived contrast also depends on hue and on text weight and size, and it can pass combinations that are genuinely hard to read while failing some that are fine. The APCA method under development for future guidance models perception more carefully and produces noticeably different recommendations, particularly for light text on dark backgrounds where the current formula is known to be unreliable.

A worked example: choosing text over a background

A blue of 3B82F6 gives 48% brightness and a recommendation of white text, and checking against the standard confirms it: white on that blue reaches a contrast ratio around 3.7, which passes for large text and fails the 4.5 threshold for normal body text, while black on it reaches around 5.7 and passes. So the simple recommendation and the standard disagree for this colour at normal text size, which is exactly the kind of mid-range case where the approximation is least reliable. The practical lesson is to use a proper contrast checker for anything that matters rather than a brightness heuristic. Several further points affect real readability beyond the ratio. Font weight matters, since thin fonts at the same contrast are harder to read and the standard's large-text allowance accounts partly for this. Antialiasing changes effective contrast at edges. Light text on a dark background appears to bleed outward and can look bolder and blurrier, which is why some designers reduce font weight for dark themes. Ambient lighting and screen brightness change perceived contrast substantially. And colour vision deficiency affects roughly one in twelve men, which is why colour should never be the only channel carrying information.

Deciding how to build an accessible palette

Start from contrast requirements rather than from aesthetics, since retrofitting contrast onto a chosen palette usually means abandoning colours. Establish the text and background pairs that must pass, check them against the standard's thresholds, and build outward from there. Use a perceptually uniform colour space such as OKLCH for generating variations, since equal numeric steps correspond to roughly equal perceived steps, which HSL does not provide and which is why HSL-generated palettes look uneven with yellows appearing washed out and blues appearing heavy. Test with simulated colour vision deficiencies, since red and green combinations that are clearly distinct to most viewers can be indistinguishable to others, and never rely on colour alone to convey state, adding an icon, pattern, or label. Check contrast for non-text elements too, since interactive controls and meaningful graphics have their own 3 to 1 requirement. Test in both light and dark themes, since a palette that works in one frequently fails in the other. And test on real devices at realistic brightness, since a design checked on a bright calibrated monitor can be unreadable on a phone outdoors, which is a common failure that no automated checker catches.

Complementary colours and why the naive inversion is wrong

Inverting each channel produces the arithmetic complement, and it is not the complementary colour in any of the senses designers usually mean. On the traditional artists' colour wheel, based on red, yellow, and blue primaries, the complement of blue is orange. On the RGB wheel used for light, the complement of blue is yellow. Inverting the channels of a blue gives a different value again, since the inversion operates in the encoded rather than perceptual space and does not preserve lightness. A colour and its channel inversion also do not necessarily contrast well, which is the property people usually want from a complement. For colour harmony, working in a hue-based space and rotating the hue by 180 degrees gives a proper complement, and rotating by other amounts gives the analogous, triadic, and split-complementary relationships that palette tools implement. Those relationships come from colour theory that is more convention than physics, and the traditional wheel's red-yellow-blue primaries are not how light or ink actually mixes, which is why it disagrees with both RGB and CMY. That said, the conventions describe how combinations are perceived and used culturally, so they remain practically useful even where the underlying model is not physically accurate.

Variations: brightness formulas and colour relationships

Several brightness approximations circulate: the weighted formula used here, the older luma coefficients from analogue television, the newer coefficients for high definition, and the linearised relative luminance used by accessibility standards. They agree broadly and differ enough to change borderline decisions. Perceived lightness in CIELAB uses a cube-root transfer and is more uniform still. For colour relationships, complementary means opposite on a wheel, analogous means adjacent, triadic means three evenly spaced, and split-complementary uses the two neighbours of the complement, all being conventions from colour theory rather than physical facts. Monochromatic palettes vary lightness and saturation at fixed hue. Tints, shades, and tones add white, black, and grey respectively. For accessibility, contrast ratio is the current standard measure with APCA under development. Colour blindness simulation filters model the common deficiencies. For generating palettes programmatically, perceptually uniform spaces produce better results than HSL, and several tools now expose OKLCH directly, which browsers support in CSS.

Using colour tools well

Treat the brightness figure as an approximation, since the accessibility standard linearises channels first and the simple weighted average disagrees on mid-range colours where decisions are closest. Check text and background pairs with a proper contrast checker, aiming for 4.5 to 1 for normal text and 3 to 1 for large text. Remember that non-text interface elements have their own 3 to 1 requirement. Weight green most heavily when reasoning about brightness, since it contributes over half of perceived luminance while blue contributes about a tenth. Build a palette from contrast requirements outward rather than retrofitting contrast onto chosen colours. Generate variations in a perceptually uniform space such as OKLCH rather than HSL, whose lightness is not perceptual. Test with colour vision deficiency simulation and never let colour alone carry information. Test in both light and dark themes and on real devices at realistic brightness. And treat the channel inversion as an arithmetic operation rather than a colour-theory complement, which comes from rotating hue instead.

What people get wrong

• Relying on a brightness threshold to choose text colour, when the accessibility standard linearises channels first and the two disagree on the mid-range colours where the decision is closest.
• Averaging the three channels equally to judge brightness, when green contributes over half of perceived luminance and blue about a tenth.
• Treating channel inversion as a complementary colour, when a proper complement comes from rotating hue and the inversion neither preserves lightness nor guarantees contrast.
• Checking contrast only on a bright calibrated monitor, when the same design can be unreadable on a phone outdoors and no automated checker catches that.

Where the math comes from

Brightness is computed as a weighted sum of the channels, with weights of roughly 0.30 for red, 0.59 for green, and 0.11 for blue, reflecting the eye's differing sensitivity by wavelength. Accessibility standards instead linearise each channel to undo the sRGB transfer function before applying weights of 0.2126, 0.7152, and 0.0722, then take a ratio between two colours.

Questions and answers

Related calculators

GCD and LCM · Arithmetic Series · Equation of Circle · Probability · Trapezoid Area