What a 4.5:1 Contrast Ratio Actually Means

WCAG asks for 4.5:1 on body text. It’s a ratio between two relative luminance values, it runs from 1:1 to 21:1, and it has almost nothing to do with how different two colours look.

How the number is built

Take both colours. For each one, convert the sRGB channels to linear light, then weight them: red 21.26%, green 71.52%, blue 7.22%. That gives relative luminance, L, from 0 for black to 1 for white.

Then:

ratio = (L_lighter + 0.05) / (L_darker + 0.05)

The 0.05 is a flare allowance — it models light scattering in a real room on a real screen, and it’s why the scale tops out at 21:1 rather than running to infinity.

The green weighting is the part with consequences. Green contributes roughly ten times what blue does. That’s why pure blue on black fails badly while pure yellow on black passes comfortably, even though both feel vivid.

The thresholds

“Large” is 18.66px regular or 14px bold in CSS pixels. Both parts count — 14px bold qualifies, 14px regular doesn’t.

The 3:1 UI rule is the one most often missed. It covers the border of a text input, the outline of a checkbox, the focus ring, the bar in a chart you’re meant to read. A 1px hairline in a pale grey is a common failure, and it fails on the control people most need to find.

Four things the number does not tell you

It doesn’t model colour blindness. Red and green of similar luminance can pass at 4.5:1 and still be indistinguishable to a substantial minority of users. Contrast and hue-blindness are separate problems and passing one says nothing about the other. That’s the reasoning behind the separate rule that information must never be carried by colour alone.

It doesn’t cover text over images. The ratio needs two flat colours. Text on a photograph has a different ratio in every region. You have to test the worst region, which usually means adding a scrim rather than measuring.

It doesn’t account for font weight. A 300-weight face at 4.5:1 is genuinely harder to read than a 600-weight face at the same ratio. The formula sees identical numbers. WCAG 3 is expected to address this; today’s rules don’t.

It doesn’t transfer between themes. This is the practical one. A colour that passes on white can fail badly on a dark background, and inverting a palette does not preserve ratios. Every pair has to be checked in both themes — the brand blue on this site is a different hex in dark mode for precisely that reason, because the light-mode value dropped to about 3.5:1 on the dark background and failed.

Fixing a failure

Change lightness, not hue. Hue barely moves the number; lightness moves it a lot, and it keeps the design recognisable.

Some measured examples, all against white:

Those first two are the reason the category gradients on this site carry icons and never body copy. Both clear the 3:1 needed for a graphic; neither clears 4.5:1 for text. Same colour, different rule, different answer.

Check a pair in both themes with our Colour Contrast Checker. It runs in the page, so you can paste an unreleased brand palette into it without that palette going anywhere.

What automated checking can’t do

Contrast is one of the few accessibility rules a machine can decide with certainty. That makes it unrepresentative.

Automated tools catch roughly 30–40% of accessibility barriers. The rest — whether your alt text is accurate, whether the tab order makes sense, whether an error message says something useful, whether a custom control behaves the way a screen reader user expects — needs a person. A page that passes every automated check can still be unusable.

So treat a green tick as one box ticked, not a verdict.

The short version

4.5:1 for body text, 3:1 for large text and UI components. It’s a luminance ratio weighted heavily towards green, so it says nothing about hue and nothing about colour blindness. Check every pair in both light and dark, and change lightness rather than hue to fix a failure.