Color Contrast Checker
Enter two hex colors to see their WCAG contrast ratio and instant AA / AAA pass-or-fail verdicts for normal text, large text, and UI components. Live as you type, completely free, and entirely in your browser.
Large text sample
Normal body text — the quick brown fox jumps over the lazy dog.
Contrast ratio
14.72:1
| Conformance level | Requirement | Result |
|---|---|---|
| Normal text — AA | ≥ 4.5:1 | Pass |
| Normal text — AAA | ≥ 7:1 | Pass |
| Large text — AA | ≥ 3:1 | Pass |
| Large text — AAA | ≥ 4.5:1 | Pass |
| UI components & graphics | ≥ 3:1 | Pass |
Large text means 18pt (24px) regular, or 14pt (18.66px) bold, and above. All computation runs locally in your browser using the WCAG 2.x relative-luminance formula.
What this tool does, and why contrast matters
Contrast ratio measures how distinguishable text is from the surface behind it. The Web Content Accessibility Guidelines define a precise formula and a set of thresholds, and this tool applies them exactly: it linearizes each color's sRGB channels, computes a relative luminance, and returns the ratio of lighter to darker. Values run from 1:1 for identical colors up to 21:1 for black on white.
The verdicts map to real requirements. AA — the level most accessibility laws and procurement rules target — needs 4.5:1 for body text and 3:1 for large text. AAA raises that to 7:1 and 4.5:1. WCAG 2.1 also added a 3:1 rule for non-text elements: input borders, focus rings, button outlines, and informative icons. We surface that check too, because it is the one teams most often miss.
Everything is computed locally as you type — no color values are uploaded, and the live preview renders your exact pairing so you can sanity-check the number against your own eyes. Accessibility is not a cosmetic afterthought: in the United States it intersects with the ADA and Section 508, and poor contrast is one of the most frequently cited issues in accessibility audits. We bake conformance into the interfaces we build — explore our web development services.
One caveat: passing contrast is necessary but not sufficient. Never rely on color alone to convey meaning, always provide a visible focus state, and structure content semantically so it works with a keyboard and a screen reader. Contrast is simply the easiest dimension to verify objectively, which makes it a sound place to start.
How to use it
Set your foreground (text) and background colors using the swatch pickers or by typing a hex value — both #rgb and #rrggbb shorthand work. The ratio and the AA / AAA table update live, and the preview panel shows your colors on real sample text. Use “Swap colors” to flip foreground and background. Nothing is stored, so a refresh clears everything.
FAQs
How is the contrast ratio calculated?
It follows the WCAG 2.x formula exactly. Each color's sRGB channels are linearized — divided by 255, then gamma-corrected — and combined into a relative luminance using the weights 0.2126 red, 0.7152 green, and 0.0722 blue. The ratio is (lighter luminance + 0.05) divided by (darker luminance + 0.05). The result ranges from 1:1 (identical colors) to 21:1 (pure black on pure white). All of this runs locally in your browser.
What do AA and AAA mean?
AA and AAA are conformance levels in the Web Content Accessibility Guidelines. For normal body text, AA requires a contrast ratio of at least 4.5:1 and AAA requires 7:1. For large text — 18pt (24px) regular or 14pt (18.66px) bold and larger — the thresholds drop to 3:1 for AA and 4.5:1 for AAA, because larger glyphs remain legible at lower contrast. AA is the level most legal and procurement requirements target; AAA is an enhanced bar that is not always achievable for every design.
What counts as large text?
WCAG defines large text as at least 18 point (roughly 24 CSS pixels) for regular weight, or at least 14 point (roughly 18.66 CSS pixels) when bold. Anything smaller is treated as normal text and must meet the stricter ratios. This distinction matters because hitting AA for a small caption is far harder than for a big heading, so the same color pair can pass for large text and fail for body copy.
Does this also cover icons and form controls?
Yes. WCAG 2.1 added a non-text contrast rule requiring a 3:1 ratio for user-interface components and meaningful graphics — think input borders, button outlines, focus indicators, and icons that convey information. We surface that 3:1 check alongside the text levels, because teams frequently nail their text contrast but ship a checkbox border or focus ring that is effectively invisible against the background.
Is contrast alone enough for accessibility?
No — contrast is necessary but not sufficient. You also need to avoid using color as the only way to convey meaning (so add icons, labels, or patterns), provide visible focus states, support keyboard navigation, and structure content with proper semantic HTML and ARIA where needed. Contrast is the easiest win to verify, which is why it is a good starting point, but a genuinely accessible interface considers the whole experience for users with low vision, color blindness, and motor or cognitive differences.
Related tools
Related engineering reading
All postsAdding AI Features to Your SaaS (2026)
Where AI helps, build-vs-API trade-offs, evals, guardrails, and shipping without torching margins.
Read postAPI Rate Limiting Strategies for 2026
Token bucket vs sliding window, per-key quotas, 429 semantics, and where to enforce limits.
Read postAPI Security Best Practices (2026)
Auth, rate limiting, input validation, secrets, and the OWASP API Top 10.
Read post
Need an interface that is accessible by design?
Contrast is one slice of accessibility — focus states, keyboard support, and semantic structure all matter for ADA and Section 508 alignment. We build web apps with conformance baked in from the first commit. Talk to us about a new build or an accessibility-focused review.
Or reach us directly: beltz@quantlabusa.dev