WCAG Contrast Checker
Pick a foreground and background color, see the contrast ratio and WCAG pass/fail at a glance. Live preview shows real text on the actual background — no guessing whether AA passes.
Why check WCAG contrast?
- Validating a new brand color against your existing background before shipping it as a design token.
- Auditing an existing site's link, button, and body-text colors during an accessibility review.
- Deciding whether a 14pt label needs to bump up to bold to qualify for the looser large-text threshold.
- Picking which of two near-identical greys passes AA on a #fafafa card background.
- Generating proof for a compliance ticket — paste the ratio and pass/fail screenshot into the issue.
- Iterating on a dark-mode palette where every accent needs to clear AA against a near-black background.
How it works
Each color is converted from sRGB to relative luminance using the WCAG 2.1 formula: each channel is gamma-corrected (linearized) — values ≤ 0.03928 are divided by 12.92, larger values use the ((c + 0.055) / 1.055)^2.4 curve. The three linear channels are weighted (0.2126·R + 0.7152·G + 0.0722·B) to produce a luminance value between 0 and 1. The contrast ratio is (L_lighter + 0.05) / (L_darker + 0.05), giving a number between 1 and 21. AA needs 4.5:1 for normal text, 3:1 for large; AAA tightens that to 7:1 and 4.5:1.
Frequently asked questions
What counts as 'large text' in WCAG?
18pt regular or 14pt bold. The reasoning is that bigger letterforms are easier to read at lower contrast, so AA only requires 3:1 instead of 4.5:1 (and AAA wants 4.5:1 instead of 7:1).
Why does my color picker not match my hex input?
The two are bidirectionally synced — typing a valid hex updates the picker, and dragging the picker updates the hex field. They only desync briefly while you're typing an incomplete hex (like #3b8 — only 4 chars). Finish the value and they align.
Does this account for opacity or rgba()?
No — WCAG ratios are defined for solid foreground on solid background. If your text is semi-transparent, compute the effective color first (background blend) and run that through the checker.
What about non-text contrast (icons, borders)?
WCAG 2.1 §1.4.11 requires 3:1 for UI components and graphical objects. The 'AA large' cell here uses the same threshold, so you can read it as 'passes for icons/borders' too.
Is this checker authoritative?
It implements the spec verbatim — same numbers as Chrome DevTools, axe-core, and the official W3C contrast checker. APCA (the proposed successor) gives different scores and isn't part of WCAG 2.x yet, so we stick with the current standard.
About this tool
WCAG contrast ratios are how the web codifies 'is this readable.' The formula sounds intricate but the pieces are well-grounded: gamma-correct each channel back to linear light, weight by human luminosity sensitivity (we see green far better than blue), and compare lightest to darkest. The 4.5:1 and 7:1 thresholds aren't arbitrary either — they correspond to roughly the worst-case contrast a person with 20/40 or 20/80 vision can resolve. Designing within them isn't gold-plating: globally, somewhere between 3% and 7% of users have a vision impairment that makes low-contrast text genuinely unusable. Building this into your design loop early (rather than as a post-launch audit) saves the expensive late-stage rework when an a11y review fails the brand color.