What the WCAG contrast ratio measures
The contrast ratio compares how much light two colours emit, on a scale that runs from 1:1 for two identical colours to 21:1 for black against white. It is the quantity the Web Content Accessibility Guidelines use to decide whether text is readable, and it is written into procurement rules and accessibility law in many jurisdictions through WCAG conformance requirements.
The ratio deliberately ignores hue. Two colours can be violently different — bright red and bright green, say — and still fail, because what matters for reading is the difference in luminance, not in colour. Red at #FF0000 and green at #00FF00 differ by every hue measure you could name, yet their contrast ratio is only 2.91:1, which fails for body text. That is also why contrast-based design serves people with colour vision deficiencies: a luminance difference survives any colour-blindness simulation, while a hue difference may not.
Three success criteria use the ratio. SC 1.4.3 Contrast (Minimum), Level AA, requires 4.5:1 for normal text and 3:1 for large text. SC 1.4.6 Contrast (Enhanced), Level AAA, raises those to 7:1 and 4.5:1. SC 1.4.11 Non-text Contrast, Level AA, requires 3:1 for the visual information needed to identify user interface components and states, and for graphics needed to understand content. All three carry exemptions: incidental text, text in a logotype, inactive controls and purely decorative graphics are out of scope.
“Large text” has a precise definition: at least 18 point, or at least 14 point if bold. At the standard 96 dpi mapping that is 24 CSS pixels, or 18.66 CSS pixels bold.
The formula and the two things people get wrong in it
The ratio itself is simple: C = (L₁ + 0.05) / (L₂ + 0.05), where L₁ is the larger of the two relative luminances and L₂ the smaller. Because the larger always goes on top, the ratio is symmetric — swapping foreground and background changes nothing.
The first thing people get wrong is skipping the linearisation. Screen colour values are gamma-encoded, so #808080 is not half as bright as white; it is about 21.6% as bright. Before weighting the channels you must undo that encoding: c_lin = c/12.92 when the normalised channel is at or below 0.03928, and ((c + 0.055)/1.055)^2.4 otherwise. Then relative luminance is L = 0.2126·R + 0.7152·G + 0.0722·B on the linearised values. Those weights are the sRGB luminance coefficients, and they are why green dominates: green light contributes more than seven times what an equal amount of blue does.
The second is forgetting the 0.05. It is added to both luminances and it is not a fudge factor — it stands in for ambient light reflecting off the screen surface, which never lets a real black be truly black. It also keeps the formula from dividing by zero when one colour is pure black, and it is why the maximum possible ratio is 21 rather than infinity: (1 + 0.05) ÷ (0 + 0.05) = 21.
One consequence worth internalising: the 0.05 compresses contrast at the dark end. Moving a dark grey a little darker buys much more ratio than moving a light grey a little lighter, because the denominator is small. That is why dark themes are harder to get right — small luminance changes swing the ratio a long way.
Worked example: is #767676 grey readable on white?
Grey #767676 on a white #FFFFFF background is the classic borderline case, so it is worth working through by hand.
- Read the channels. 0x76 = 7×16 + 6 = 118, so the foreground is rgb(118, 118, 118). The background is rgb(255, 255, 255).
- Normalise the foreground. 118 ÷ 255 = 0.462745 on all three channels.
- Linearise. 0.462745 is above 0.03928, so use the power branch: (0.462745 + 0.055) ÷ 1.055 = 0.490754, and 0.4907542.4 = 0.181240.
- Weight the channels. All three are equal, and 0.2126 + 0.7152 + 0.0722 = 1, so the foreground luminance is just 0.18124.
- Background luminance. Each channel normalises to 1.0, linearises to 1.0, so L = 1.0000.
- Add the flare term. Lighter: 1.0000 + 0.05 = 1.05. Darker: 0.18124 + 0.05 = 0.23124.
- Divide. 1.05 ÷ 0.23124 = 4.54:1.
4.54 clears the 4.5:1 required by SC 1.4.3 for normal text, with 0.04 to spare — which is why #767676 is the lightest neutral grey that passes on white, and why #777777 (4.48:1) does not. It fails SC 1.4.6 at Level AAA, which wants 7:1. Nudging the foreground to #595959 gives 7.00:1 and clears AAA for normal text.
Compare a mid grey, #808080: 128 ÷ 255 = 0.501961, linearised 0.215861, so the ratio against white is 1.05 ÷ 0.265861 = 3.95:1. That passes SC 1.4.3 for large text and for UI components, and fails it for body copy — a single colour landing on both sides of the line depending on where you use it.
How to read the result
Compare against the threshold that matches the element, not against a single number you remember. Body text needs 4.5:1. A 24-pixel heading needs 3:1. The border of a text input, the fill of a checked checkbox, the line in a chart that carries meaning: all 3:1 under SC 1.4.11. Placeholder text is still text and still needs 4.5:1, which is where a great many designs fail.
Treat the thresholds as floors rather than targets. 4.5:1 was chosen to approximate the readability that a person with 20/40 vision gets from a 7:1 contrast at normal acuity, so a pair that lands at 4.51:1 is genuinely marginal for a reader with low vision, on a dim laptop screen, in sunlight. Where you have room, aim higher — especially for long-form reading.
Do not read the ratio as a perceptual scale. The gap between 3:1 and 4.5:1 looks larger to a reader than the gap between 15:1 and 21:1, because the flare term compresses the top of the range. A design that moves from 12:1 to 18:1 has gained almost nothing anyone will notice; one that moves from 2.5:1 to 4.5:1 has changed the page.
Watch for the two situations the ratio cannot see. First, semi-transparent colours: a foreground at 60% opacity has to be composited against whatever is actually behind it before the contrast is meaningful, so flatten the stack and enter the resulting colour. Second, gradients and images behind text: the correct approach is to test the worst point, not an average, because a reader encounters the whole area. Neither case is a defect in the formula — it is a reminder that contrast is a property of the rendered pixels.
WCAG contrast thresholds and what they apply to
| Success criterion | Level | Applies to | Required ratio |
|---|---|---|---|
| 1.4.3 Contrast (Minimum) | AA | Normal text and images of text | 4.5:1 |
| 1.4.3 Contrast (Minimum) | AA | Large text: 18 pt / 24 px, or 14 pt / 18.66 px bold | 3:1 |
| 1.4.6 Contrast (Enhanced) | AAA | Normal text and images of text | 7:1 |
| 1.4.6 Contrast (Enhanced) | AAA | Large text | 4.5:1 |
| 1.4.11 Non-text Contrast | AA | UI component states and boundaries | 3:1 |
| 1.4.11 Non-text Contrast | AA | Graphics required to understand content | 3:1 |
Exemptions: incidental text, text in a logotype or brand name, inactive user interface components, and purely decorative graphics. Both 1.4.3 and 1.4.6 also exempt text that is part of a picture containing significant other visual content.
Neutral greys on white, and where each one stops passing
| Grey | Channel value | Relative luminance | Ratio on white | Highest criterion it meets |
|---|---|---|---|---|
| #000000 | 0 | 0.0000 | 21.00:1 | AAA normal text |
| #404040 | 64 | 0.0513 | 10.37:1 | AAA normal text |
| #595959 | 89 | 0.1000 | 7.00:1 | AAA normal text |
| #6B6B6B | 107 | 0.1472 | 5.33:1 | AA normal text |
| #767676 | 118 | 0.1812 | 4.54:1 | AA normal text |
| #808080 | 128 | 0.2159 | 3.95:1 | AA large text and UI |
| #949494 | 148 | 0.2961 | 3.03:1 | AA large text and UI |
| #999999 | 153 | 0.3185 | 2.85:1 | None |
| #CCCCCC | 204 | 0.6038 | 1.61:1 | None |
#767676 is the lightest grey that reaches 4.5:1 on white, and #949494 the lightest that reaches 3:1. One step lighter in each case drops below the line.
Mistakes that produce a false pass
- Testing against the page background instead of the actual background. A card, a hover state or a translucent overlay changes the colour behind the text. Flatten what is really rendered and test that.
- Ignoring placeholder and helper text. Both are text under SC 1.4.3 and both need 4.5:1. Light-grey placeholders are one of the most common failures in shipped forms.
- Forgetting the focus indicator and the component border. SC 1.4.11 covers the boundary that identifies a control and the visual state that shows it is checked or selected, at 3:1 against the adjacent colour.
- Assuming a hue change is enough. Red on green fails at 2.91:1 despite being maximally different in hue, because contrast is a luminance comparison.
- Rounding up to a pass. 4.49:1 is a fail. Tools that display one decimal place can hide the difference, so read at least two.
- Testing only the light theme. The flare term compresses ratios at the dark end, so a palette that works on white often fails when inverted. Test every theme independently.
- Treating contrast as the whole of readability. Font size, weight, line length, letter spacing and the background texture all matter. A 21:1 hairline typeface at 10 px is still hard to read.
Where this sits, and what comes next
Contrast is the last step of a colour workflow and the first step of an accessibility audit. If your palette is defined in HSL or HSV, convert it first — the HEX, RGB and HSL converter also reports the same relative luminance value this page uses, so you can carry it straight across. Nothing about lightness in HSL predicts contrast: hsl(60, 100%, 50%) and hsl(240, 100%, 50%) both claim 50% lightness while differing by a factor of nearly thirteen in luminance.
If text sits over an image or a letterboxed video, the bar colour and the picture edge both matter — the aspect ratio calculator tells you exactly where the bars fall, so you know which region the text will actually land on. And on a very high-density panel, thin type at small sizes renders with fewer effective luminance levels per stem; the pixel density calculator gives the density figure that decides how much antialiasing a glyph edge gets.
Use something other than this ratio when the question is about non-standard rendering. WCAG's formula assumes sRGB and a self-luminous display; it is not calibrated for print, for e-ink, or for wide-gamut content that has not been converted. The W3C is also developing a perceptually weighted successor algorithm intended to model dark themes and thin fonts better than the current ratio does, but as of WCAG 2.2 the formula on this page is the normative one, and it is what conformance is measured against.