Audited ·Last updated 28 Jul 2026·6 citations·Tier 1·0 uses

Contrast Ratio Calculator (WCAG)

Check the WCAG colour contrast ratio between two colours and see whether it passes AA or AAA for body text, large text or interface components.

Contrast Ratio Calculator

The text or component colour. Accepts #RRGGBB, #RGB, a bare hex string, or rgb(26, 26, 26). Named colours are not supported.
The colour directly behind the foreground. If the foreground is semi-transparent, work out the composited colour first — alpha has no single luminance.
What is this colour pair used for?
Contrast ratio
15.3421
(L1 + 0.05) ÷ (L2 + 0.05), where L1 is the relative luminance of the lighter colour and L2 that of the darker. Ranges from 1:1 for identical colours to 21:1 for black on white.
Required by this criterion
4.5:1
Margin
10.8421
Foreground relative luminance
0.0103
Background relative luminance
0.8756
Ratio
15.34:1
Verdict
Passes. 15.34:1 meets WCAG Success Criterion 1.4.3, which requires at least 4.5:1 for normal-size text at level AA — 10.84 to spare.
All WCAG thresholds
15.34:1 meets every WCAG 2.2 contrast threshold: 1.4.3 large text (3:1); 1.4.11 UI components and graphics (3:1); 1.4.3 normal text (4.5:1); 1.4.6 large text (4.5:1); 1.4.6 normal text (7:1).

Background.

Contrast ratio is one of the few accessibility requirements that is a number rather than a judgement, which is why it is also one of the few that gets checked. The W3C defines it precisely: take the relative luminance of the lighter of two colours, add 0.05, and divide by the relative luminance of the darker plus 0.05. The result runs from 1:1 for two identical colours to exactly 21:1 for black on white, and the Web Content Accessibility Guidelines set thresholds along that scale that a design either clears or does not.

The subtlety is in the word "luminance". It is not the brightness of the colour as a number in a hex code, and it is not the average of the three channels. WCAG's relative luminance first undoes the sRGB gamma encoding — each 8-bit channel is divided by 255, then either divided by 12.92 if it is below 0.04045 or run through ((c + 0.055) ÷ 1.055) raised to the power 2.4 if it is above — and then weights the three linear channels by 0.2126 for red, 0.7152 for green and 0.0722 for blue. Those weights are why green dominates: change a colour's green channel and the ratio moves sharply; change its blue channel and it barely moves at all. It is also why two colours that look equally "dark" to the eye can have very different luminances, and why guessing at contrast fails so often.

The thresholds come from three separate success criteria, and this calculator implements all of them because they apply to different things. Success Criterion 1.4.3, Contrast (Minimum), requires 4.5:1 for text and images of text, dropping to 3:1 for large-scale text — which WCAG defines as 18 point, or 14 point bold. Success Criterion 1.4.6, Contrast (Enhanced), is the level AAA version: 7:1 for normal text and 4.5:1 for large text. Success Criterion 1.4.11, Non-text Contrast, requires 3:1 for the visual information needed to identify user interface components and their states, and for the parts of graphics required to understand content. Selecting a context here does not change the ratio — the ratio is a property of the two colours — it changes which line the ratio is measured against, and the summary output reports all five verdicts at once regardless.

One constant is worth being explicit about, because published sources disagree. WCAG 2.0 and 2.1 print the sRGB piecewise threshold as 0.03928; a May 2021 erratum corrected it to 0.04045, and the W3C's own Technique G17 now carries the corrected figure. This calculator uses 0.04045. The difference is unobservable for 8-bit colour and can be shown to be: 10 ÷ 255 = 0.0392157 falls below both thresholds and 11 ÷ 255 = 0.0431373 falls above both, so no channel value in the whole 0-255 range is classified differently. That check runs as a test rather than sitting as a claim.

A word on the other contrast ratio. Display manufacturers quote a contrast ratio too — Apple publishes "1,000,000:1" for the Liquid Retina XDR panel, and televisions advertise figures in the millions. That number is the ratio of the panel's peak white luminance to its black luminance, measured in candelas per square metre on real hardware. It shares a name with the WCAG figure and nothing else: it is a measurement of a device, not a computation on two colours, and it has no bearing on whether your text is readable. This page computes the colour ratio.

Finally, the limits. The formula is defined for opaque sRGB colours, so a semi-transparent foreground must be composited against its backdrop first — the calculator will tell you rather than guess. Wide-gamut and HDR colours are outside the definition. And a passing ratio is not the same as good typography: WCAG 2.x's model is known to be imperfect for very thin fonts and for light-on-dark text, which is what the in-development APCA algorithm aims to address. APCA is not a Recommendation, so it is not implemented here.

What is contrast ratio calculator?

The WCAG contrast ratio is a number between 1 and 21 that describes how far apart two colours are in perceived lightness. It is computed as (L1 + 0.05) ÷ (L2 + 0.05), where L1 is the relative luminance of the lighter colour and L2 that of the darker, and where relative luminance is a weighted sum of the gamma-linearised sRGB channels: 0.2126·R + 0.7152·G + 0.0722·B. Because the three coefficients sum to 1, white has a luminance of exactly 1 and black exactly 0, which fixes the maximum ratio at 21:1.

The number matters because the Web Content Accessibility Guidelines set minimum ratios for readability. Success Criterion 1.4.3 requires 4.5:1 for normal text and 3:1 for large-scale text at level AA; Success Criterion 1.4.6 raises those to 7:1 and 4.5:1 at level AAA; Success Criterion 1.4.11 requires 3:1 for user interface components and meaningful graphics. The ratio is symmetric — swapping which colour is the text and which is the background cannot change it — because the formula is defined on the lighter and darker colours, not on their roles.

How to use this calculator.

  1. Enter the foreground colour — the text, icon or component colour — as a hex value such as #1A1A1A, or as rgb(26, 26, 26).
  2. Enter the background colour that sits directly behind it. If a gradient or image is behind the text, test the lightest and darkest points separately.
  3. Choose what the pair is used for. This picks the success criterion: body text, large text, or a non-text interface element, at level AA or AAA.
  4. Read the contrast ratio and compare it with the required ratio; the margin output tells you how much room you have, or how much you are short by.
  5. Check the all-thresholds summary — a pair that fails for body text often passes comfortably for headings and icons, and knowing that saves redesigning a palette.
  6. If the foreground is semi-transparent, composite it over its backdrop first and enter the resulting solid colour; alpha has no single luminance.
  7. Adjust and retest: because green carries 71.5% of the luminance weight, changing the green channel moves the ratio fastest.

The formula.

L = 0.2126·R + 0.7152·G + 0.0722·B; ratio = (L1 + 0.05) ÷ (L2 + 0.05)

The calculation runs in three stages: undo the gamma, weight the channels, then form the ratio.

Stage one is linearisation. An sRGB value stored in a file is gamma-encoded, so the number 128 does not carry half the light energy of 255. WCAG's Technique G17 specifies the exact inverse transfer function: divide the 8-bit channel by 255 to get c, then take c ÷ 12.92 if c ≤ 0.04045, and ((c + 0.055) ÷ 1.055) to the power 2.4 otherwise. The linear branch exists because the pure power function has an infinite slope at zero, which would make the darkest values numerically unstable; the crossover is chosen so the two pieces meet smoothly.

Stage two is the luminance weighting. Add the three linearised channels in the proportions 0.2126 red, 0.7152 green, 0.0722 blue. These are the luminance coefficients of the sRGB primaries, and they encode the fact that the human eye is far more sensitive to green light than to blue. They sum to exactly 1, which is what makes L(white) = 1 and L(black) = 0.

Stage three is the ratio itself: (L1 + 0.05) ÷ (L2 + 0.05) with L1 the lighter luminance. The 0.05 in both terms is a flare allowance — it models the ambient light reflecting off a real screen, which never lets true black reach zero in practice. Without it the ratio against pure black would be infinite; with it the maximum is (1 + 0.05) ÷ (0 + 0.05) = 21 exactly. And because the formula names the lighter and darker colours rather than the foreground and background, it is symmetric: white text on a black button and black text on a white button have exactly the same ratio.

Working an example through: #C4622D is (196, 98, 45). Each channel over 255 gives 0.7686, 0.3843 and 0.1765, all above 0.04045, so all three take the power branch and linearise to 0.5520114015, 0.1221387722 and 0.0262412219. Weighted, those contribute 0.1173576240, 0.0873536499 and 0.0018946162, summing to a relative luminance of 0.2066058901. Doing the same to #FBF8F2 = (251, 248, 242) gives 0.9405483784. The background is lighter, so the ratio is (0.9405483784 + 0.05) ÷ (0.2066058901 + 0.05) = 0.9905483784 ÷ 0.2566058901 = 3.8602.

Running the thresholds against that: 3.86 clears the 3:1 that SC 1.4.3 sets for large text and the 3:1 that SC 1.4.11 sets for interface components, but falls short of the 4.5:1 SC 1.4.3 requires for body text, by 0.64. The practical reading of a result like that is not "change the brand colour" but "use it for headings, icons and borders, and not for paragraphs".

A worked example.

Example

Take a real palette decision: Quanta's own amber accent, #C4622D, set on its own paper surface, #FBF8F2, used for body copy. The amber is (196, 98, 45). Dividing by 255 gives 0.7686, 0.3843 and 0.1765 — all three above the 0.04045 threshold, so all three take the power branch of the sRGB inverse transfer function and linearise to 0.5520114015, 0.1221387722 and 0.0262412219. Weighting those by 0.2126, 0.7152 and 0.0722 gives 0.1173576240 + 0.0873536499 + 0.0018946162 = 0.2066058901, the relative luminance of the amber. The paper colour, (251, 248, 242), linearises to 0.9646862479, 0.9386857285 and 0.8879231179, which weight and sum to 0.9405483784. The paper is much the lighter of the two, so it is WCAG's L1: the ratio is (0.9405483784 + 0.05) ÷ (0.2066058901 + 0.05) = 0.9905483784 ÷ 0.2566058901 = 3.8601934589, or 3.86:1. Success Criterion 1.4.3 requires 4.5:1 for normal-size text, so this pairing fails by 0.6398065411 — it is 14 per cent short. The same criterion's large-text threshold is 3:1, and Success Criterion 1.4.11's requirement for interface components is also 3:1, and 3.86 clears both comfortably. The honest conclusion is that this amber is a heading, icon and border colour, not a paragraph colour, and that the fix for body copy is a darker shade rather than a lighter background.

background Color#FBF8F2
contextaa-normal
foreground Color#C4622D

Frequently asked questions.

What contrast ratio do I need to pass WCAG?
It depends on what the colours are doing. Success Criterion 1.4.3, Contrast (Minimum), requires 4.5:1 for text and images of text, and 3:1 for large-scale text — which WCAG defines as 18 point, or 14 point bold. Success Criterion 1.4.6, Contrast (Enhanced), is the level AAA version and requires 7:1 for normal text and 4.5:1 for large text. Success Criterion 1.4.11, Non-text Contrast, requires 3:1 for the visual information needed to identify interface components and their states, and for parts of graphics needed to understand the content. Logos and purely decorative or invisible text are explicitly exempt from the text criteria.
How is the contrast ratio actually calculated?
Compute the relative luminance of each colour, then take (L1 + 0.05) ÷ (L2 + 0.05) with L1 the lighter. Relative luminance is not a simple average of the channels: each 8-bit channel is divided by 255, then linearised — divided by 12.92 if it is at or below 0.04045, otherwise raised through ((c + 0.055) ÷ 1.055)^2.4 — and the three linear values are weighted 0.2126 red, 0.7152 green and 0.0722 blue. The linearisation undoes the sRGB gamma encoding, and the weights reflect the eye's sensitivity to each primary.
Why is the maximum contrast ratio 21:1?
Because the three luminance coefficients sum to exactly 1, white has a relative luminance of 1 and black of 0. Substituting into the formula gives (1 + 0.05) ÷ (0 + 0.05) = 1.05 ÷ 0.05 = 21. The 0.05 added to both terms is a flare allowance representing ambient light reflected off the screen, which is why the ratio is capped at a finite number instead of going to infinity against pure black. The minimum, for two identical colours, is 1:1.
Does it matter which colour I put in the foreground field?
No. WCAG defines the ratio in terms of the lighter and the darker colour, not the text and the background, so swapping the two fields returns exactly the same number. White text on a dark button and dark text on a white button have identical ratios. What does change is the readability in practice — WCAG 2.x is known to model light-on-dark less well than dark-on-light — but the criterion itself is symmetric.
What counts as large text?
WCAG's own note under Success Criterion 1.4.3 says "18 point text or 14 point bold text is judged to be large enough to require a lower contrast ratio". In CSS terms 18 point is about 24 px and 14 point bold about 18.66 px at default settings, though the mapping depends on the user's base font size. Anything meeting that bar can use the 3:1 threshold at level AA, or 4.5:1 at level AAA. Text below it must meet the full 4.5:1 or 7:1.
Why does the sRGB threshold appear as 0.03928 in some places and 0.04045 in others?
WCAG 2.0 and 2.1 published the piecewise threshold as 0.03928; a W3C erratum in May 2021 corrected it to 0.04045, and Technique G17 and the WAI wiki both now carry the corrected value with a note about the change. This calculator uses 0.04045. It makes no observable difference for 8-bit colour: 10 ÷ 255 = 0.0392157 sits below both thresholds and 11 ÷ 255 = 0.0431373 sits above both, so every one of the 256 channel values is classified the same way under either constant. The test suite checks all 256 to prove it.
Is this the same as a TV's contrast ratio?
No, despite the shared name. A display's contrast ratio is the ratio of the panel's peak white luminance to its black luminance measured in candelas per square metre — Apple publishes 1,000,000:1 for the Liquid Retina XDR display, and televisions quote figures in the millions. It describes the hardware, it can only be measured rather than computed, and it says nothing about whether a particular pair of colours is legible on it. The WCAG ratio calculated here is a property of two colour values and tops out at 21:1 by construction.
How do I handle transparency or a semi-transparent overlay?
Composite it first. A colour with an alpha channel has no single luminance, because what reaches the eye depends on whatever is behind it. Work out the resulting solid colour — for a foreground F over a backdrop B at opacity a, each channel is a·F + (1 − a)·B computed on the 8-bit values — then enter that solid colour here. The calculator rejects rgba() input rather than silently assuming a white backdrop, which is a common source of wrong passes in automated tooling.
My text sits on a photo or gradient — which colour do I test?
Test the worst case, and usually more than one point. For a gradient, test the ratio at the lightest and darkest points the text overlaps; the text has to pass at both. For a photograph, the honest answer is that no single test is sufficient, which is why the usual fix is to place a solid or heavily blurred scrim between the image and the text, or to give the text its own background. Sampling a few of the lightest pixels under the text is a reasonable approximation, but only if the image cannot change.
Which channel should I change to fix a failing ratio fastest?
Green, by a wide margin. Green carries 0.7152 of the luminance weight against red's 0.2126 and blue's 0.0722, so a given change to the green channel moves the ratio roughly three and a half times as much as the same change to red and nearly ten times as much as the same change to blue. That is why darkening a blue by dropping its blue channel barely helps, and why two colours that look similarly dark can sit either side of a threshold.
Does passing the contrast check mean my text is accessible?
It means it meets one specific, measurable requirement. Contrast is necessary but not sufficient: very thin fonts, tight letter-spacing, small sizes, and text over moving backgrounds can all be hard to read at a technically passing ratio. The WCAG 2.x model is also known to be imperfect, particularly for light text on dark backgrounds, which is what the in-development APCA algorithm is intended to address for WCAG 3. APCA is not yet a W3C Recommendation, so this calculator implements the WCAG 2.x formula that is currently normative.
What colour formats can I enter?
Six-digit hex with or without the leading hash (#C4622D or C4622D), three-digit shorthand hex (#C63, which expands to #CC6633 by doubling each digit), and functional rgb() notation with commas or spaces (rgb(196, 98, 45) or rgb(196 98 45)). Case does not matter and surrounding whitespace is trimmed. Named colours such as "rebeccapurple", HSL notation and rgba() with an alpha channel are rejected with an explanatory message rather than being guessed at.

References& sources.

  1. [1]W3C, Technique G17 (Web Content Accessibility Guidelines 2.2) — the relative luminance formula 'L = 0.2126 * R + 0.7152 * G + 0.0722 * B' with 'if RsRGB <= 0.04045 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4', and the contrast ratio '(L1 + 0.05) / (L2 + 0.05)'. The page notes the 0.04045 constant was updated in May 2021 from 0.03928.
  2. [2]W3C, Understanding Success Criterion 1.4.3: Contrast (Minimum) — 'a contrast ratio of at least 4.5:1', 'Large-scale text and images of large-scale text have a contrast ratio of at least 3:1', and '18 point text or 14 point bold text is judged to be large enough to require a lower contrast ratio'.
  3. [3]W3C, Understanding Success Criterion 1.4.6: Contrast (Enhanced) — 'a contrast ratio of at least 7:1' for text, with 'at least 4.5:1' for large-scale text.
  4. [4]W3C, Understanding Success Criterion 1.4.11: Non-text Contrast — 'a contrast ratio of at least 3:1 against adjacent color(s)' for user interface components and graphical objects.
  5. [5]W3C WAI, Relative luminance (WCAG working group wiki) — confirms the piecewise formula and records the erratum that 'the correct threshold for the piecewise equation is 0.04045 and not the 0.03928 that is listed', noting the difference is not practically significant for 8-bit colour.
  6. [6]Apple — MacBook Pro (14-inch, 2021) Technical Specifications: 'XDR (Extreme Dynamic Range) 1,000,000:1 contrast ratio'. Cited only to distinguish a display's measured contrast ratio from the WCAG colour contrast ratio computed here.

In this category

Embed

Quanta Pro

Paid features are coming later.

  • All 590 calculators remain free
  • No billing is enabled
Coming soon