What this does
Type or pick a foreground and a background color and the tool computes the WCAG 2.x contrast ratio between them, then shows a pass/fail badge for each of the four thresholds that matter in an accessibility audit: AA and AAA for normal text, AA and AAA for large text. The preview block above the results is painted with your actual colors, so you see real body copy and a real large heading rather than a colored square. The math is a few lines of relative-luminance arithmetic that run in your browser as you type.
What contrast ratio do I need to pass WCAG AA?
For normal-size text, WCAG 2.x success criterion 1.4.3 requires at least
4.5 : 1. For large text the bar drops to 3 : 1.
The AAA level (criterion 1.4.6) raises those to 7 : 1 for
normal text and 4.5 : 1 for large text. These are exactly the
four comparisons the badges make — the ratio is shown to two decimals and
each badge is a straight >= check against the number above.
#777777 on #ffffff → 4.48 : 1 normal AA ✗ large AA ✓
#767676 on #ffffff → 4.54 : 1 normal AA ✓ normal AAA ✗
#595959 on #ffffff → 7.00 : 1 normal AAA ✓
#e6e8ec on #0b0d10 → 15.86 : 1 everything ✓ (the tool's default pair)The first two rows show how narrow the margin can be: a single step of gray is the difference between passing and failing AA for body text.
What counts as large text?
WCAG defines large text as at least 18 point (24 CSS px) at regular weight, or at least 14 point (roughly 18.66 px) when bold. Anything smaller is judged against the normal-text thresholds. The preview shows a bold 30 px heading, a 20 px line and a normal-size paragraph so you can eyeball all three cases at once, but the checker itself does not measure your font — you decide which column applies to the text you are styling.
How is the contrast ratio calculated?
Each color is converted to relative luminance: every sRGB channel is
divided by 255, linearised (values at or below 0.03928 are divided by 12.92,
everything else goes through ((v + 0.055) / 1.055) ^ 2.4), then
weighted 0.2126 red, 0.7152 green, 0.0722 blue. The ratio is
(L1 + 0.05) / (L2 + 0.05) with the lighter luminance on top,
which is why black on white comes out at exactly 21 : 1 and any color against
itself is 1 : 1. Because the lighter color always goes in the numerator, the
result is the same whichever way round you enter the pair — the
Swap fg ↔ bg button only changes the preview, never the number.
Which color formats can I enter?
Hex only. Six-digit hex (#1a73e8) and three-digit shorthand
(#fff, expanded to #ffffff) are accepted, with or
without the leading #, in either case. Anything else —
rgb(), hsl(), named colors, alpha channels — is
ignored and the results keep showing the last valid pair. If you have a color
in another notation, convert it with the color converter
first, then paste the hex here. The native color pickers next to each field
stay in sync with the hex boxes whenever the text parses cleanly.
Why does a color pair that looks fine still fail?
The WCAG 2.x formula is a luminance model and nothing more. It knows nothing about hue, font weight, letter spacing or the size of the text beyond the large/normal split, so it can fail combinations that read comfortably (many saturated blues and oranges on white) and pass pairs that are genuinely hard on the eye when set in a thin typeface. The draft APCA model in WCAG 3 fixes some of this, but WCAG 2.x is still what audits, lawsuits and automated checkers measure against, so this tool sticks to the standard formula. If you are building a whole scheme rather than checking a single pair, generate candidates in the palette tool and simulate how they read under the color-blindness filters before settling on final values.