Colors
—
Large text at 24px
Body text at 15px — the size most interface copy actually is.
Fine print at 12.5px, which has to clear the same 4.5:1 as body text.
Huely/Contrast checker
Put two colors in and get the contrast ratio between them, graded against every WCAG 2.2 threshold that applies — body text, large text and non-text UI. When a pair fails, the checker proposes the smallest change that fixes it instead of leaving you to guess.
Large text at 24px
Body text at 15px — the size most interface copy actually is.
Fine print at 12.5px, which has to clear the same 4.5:1 as body text.
WCAG 2.2 sets the bar by text size, not by importance. Level AA — the level almost every legal requirement points at — asks for 4.5:1 for body text and 3:1 for large text, where large means 24px or larger, or 18.66px and bold. Level AAA raises those to 7:1 and 4.5:1.
| What | AA | AAA |
|---|---|---|
| Body text (under 24px) | 4.5:1 | 7:1 |
| Large text (24px+, or 18.66px bold) | 3:1 | 4.5:1 |
| UI components, icons, focus rings | 3:1 | — |
| Disabled controls, decorative graphics | exempt | exempt |
The row people forget is the third one. Success criterion 1.4.11 covers non-text content: an input border, a toggle, a chart segment boundary or a focus ring has to clear 3:1 against what sits next to it. A form whose text passes AAA and whose input outlines are a 1.6:1 hairline is still failing.
The usual advice — "darken the text" — is right but imprecise, and applied by hand it drags the color somewhere you did not intend. Contrast responds to lightness. Hue and saturation barely move it. So the correct repair changes lightness and holds everything else.
That is what the Fix buttons above do: they search in both directions in OKLCH, hold hue and chroma fixed, and stop at the smallest lightness change that clears the target. A brand red stays recognisably that red instead of turning into a different color that happens to pass. You get one suggestion for moving the text and one for moving the background, because which of the two you are allowed to touch is a design decision, not a math one.
The WCAG 2.x formula is a ratio of relative luminance, and it is known to be imperfect: it over-rewards dark backgrounds and can pass pairs that read poorly at small sizes, particularly for light text on dark. Treat a bare pass at 4.5:1 as the floor rather than the goal, and check the pair at the size and weight you will actually ship.
A ratio also says nothing about whether two colors are distinguishable. Two swatches can differ by hue alone, clear every contrast threshold against the page, and still be identical to a red-green color blind reader. Contrast and discriminability are separate questions — the color blindness simulator answers the second one.
4.5:1 for body text and 3:1 for large text meets WCAG 2.2 level AA, which is the level referenced by most accessibility legislation. 7:1 meets AAA. Non-text elements such as input borders, icons and focus indicators need 3:1 under success criterion 1.4.11.
Yes. Any control or meaningful graphic must reach 3:1 against its adjacent color. Purely decorative graphics and disabled controls are exempt. Text inside a button is still text, so it needs 4.5:1 against the button fill, not against the page background.
Change lightness, not hue. Contrast is driven almost entirely by lightness, so lightening or darkening a color while holding its hue and chroma will reach the threshold with the least visible drift. This checker does that search for you and stops at the smallest change that passes.
Whichever gives the higher ratio — and the crossover is not at 50% lightness. Mid-tone colors often fail against both, which is a signal that the background needs to move rather than the text. Swap the two fields here to compare both directions quickly.
No. Everything is computed in your browser, and the pair you are checking is stored only in the page URL so you can share or bookmark a result.