Contrast Checker
Check if your text and background colors meet WCAG accessibility standards, updates as you pick colors.
What is Contrast Ratio?
Contrast ratio measures how easily text can be read against its background, expressed as a number from 1:1 (no contrast, same color) to 21:1 (pure black on pure white, maximum contrast). The Web Content Accessibility Guidelines (WCAG) define minimum ratios so that text stays readable for people with low vision or color blindness, and honestly, for everyone reading on a dim screen or in bright sunlight too.
WCAG Contrast Requirements
- AA, normal text: minimum 4.5:1, the baseline most websites aim for.
- AA, large text (18pt+, or 14pt+ bold): minimum 3:1, large text is easier to read, so the bar is lower.
- AAA, normal text: minimum 7:1, a stricter standard for higher-accessibility contexts.
- AAA, large text: minimum 4.5:1.
How It's Calculated
The ratio is derived from the relative luminance of each color, a weighted measure of how bright a color appears to the human eye, where green contributes more than red, and red more than blue. The formula compares the lighter luminance to the darker one: (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter color's luminance and L2 is the darker one's.
Why This Matters
Low-contrast text is one of the most common accessibility failures on the web, and one of the easiest to fix before you ship. Checking your palette here before finalizing a design saves you from having to redo color decisions later, and helps make sure your site is usable for the widest possible audience.
Worked Examples: Testing Real Color Pairs
Pure black text on a pure white background produces the maximum possible ratio, 21:1, comfortably passing every WCAG level. A softer combination, dark indigo (#2A2E5A) on an off-white background (#FAF9F6), the default colors loaded in this tool, comes out to 12.19:1, which clears even the strict AAA threshold for normal text with a large margin. Medium gray text (#777777) on white lands at 4.48:1, just barely under the 4.5:1 AA minimum, a good illustration of how close a "safe-looking" gray can come to failing without actually passing. A lighter gray (#999999) on white drops to 2.85:1, which fails every WCAG level and is a genuinely common mistake in muted UI text. Classic hyperlink blue (#0000EE) on white checks in at 9.40:1, passing AAA comfortably, which is part of why that specific blue became a web convention in the first place. And yellow text (#FFFF00) on a white background, a combination that shows up surprisingly often in "highlight" styling, measures just 1.07:1, close to unreadable and a clear fail at every level.
Common Contrast Mistakes
Light gray text on white or near-white backgrounds. Designers often reach for gray to create visual hierarchy between primary and secondary text, but grays lighter than roughly #767676 on a white background fail AA for normal-sized text, as the worked example above shows.
Colored text on colored backgrounds without checking the pairing. Two colors can look pleasant next to each other as a palette while still failing contrast badly as text and background, since visual harmony and readability are measured completely differently.
Placeholder text styled too faintly. Placeholder text inside form fields is frequently styled at a much lower contrast than the surrounding labels, on the assumption that it's "just a hint," but users do rely on it as real content and it should still clear AA in most cases.
Assuming a brand color works everywhere it's used. A brand color chosen for its logo or marketing impact often wasn't chosen with text contrast in mind at all, and using it directly as a text color on a light or dark background is one of the most frequent sources of accessibility failures in real products.
A Practical Workflow for Fixing Failing Contrast
When a pairing fails, the fastest fix is almost always adjusting lightness rather than hue, since lightness has the biggest direct effect on relative luminance and therefore on the ratio. If dark text on a light background fails, darken the text further, or lighten the background, and re-check. If you need to preserve a specific brand hue, try shifting only its lightness and saturation while keeping the hue value fixed, this usually gets a failing pair to pass without making the color unrecognizable as the brand color. For borderline cases sitting just under a threshold, small adjustments of a few percentage points in lightness are often enough, there's rarely a need to pick an entirely different color from scratch.
Contrast Beyond Text: Buttons, Icons, and Borders
WCAG 2.1 extended contrast requirements beyond plain text to cover "non-text contrast" for meaningful UI components, icons, form field borders, and graphical objects that convey information need a minimum 3:1 ratio against their adjacent background. This is easy to overlook because it's not about reading words, but a low-contrast input field border or an icon that blends into its background creates the same kind of barrier for low-vision users that illegible body text does. When using this checker for interface elements rather than text, apply the same tool and the 3:1 large-text threshold as a reasonable proxy, since the underlying luminance math is identical.
A Brief History of the WCAG Contrast Requirement
The contrast ratio formula and its thresholds were formalized in WCAG 2.0, published by the W3C in 2008, building on earlier accessibility research into how relative luminance affects legibility for people with low vision. The specific numbers, 4.5:1 and 7:1, weren't arbitrary, they were chosen based on studies of readability across a range of visual impairments, aiming to set a bar that's achievable for typical design work while still meaningfully improving access. These same thresholds remain the basis for accessibility law in many countries today, including the ADA in the United States and the EN 301 549 standard in the EU, which is why passing AA specifically, rather than just "looking readable," has become a practical requirement rather than only a best practice.
Choosing Colors That Pass From the Start
It's far easier to design with contrast in mind from the beginning than to retrofit a finished palette that turns out to fail. A reliable rule of thumb: if your background sits in the light range (roughly above 70% lightness in HSL terms), keep primary text colors below about 35% lightness, and if your background is dark, keep text above about 75% lightness, this alone gets most pairings comfortably past AA before you even check the exact ratio. Saturated, mid-lightness colors are the riskiest category for text, a vivid orange, teal, or purple sitting around 50% lightness tends to land in a gray zone where it looks bold as a swatch but reads poorly as body copy, which is exactly why so many design systems reserve their most saturated brand colors for buttons, icons, and accents rather than for paragraphs of text. Building this habit into an early design phase, checking a candidate text and background pairing here before it gets baked into a component library, saves far more time than discovering the failure during an accessibility audit months later.
Testing More Than One Pair
Most real interfaces use more than a single text-on-background combination, body text on a card, a heading on a hero section, white text on a colored button, muted labels on a sidebar, each of these is a separate pairing that needs its own check. A palette that passes for its primary text and background combination can still fail badly for a secondary combination, like light gray metadata text on a colored badge, if that pairing is never explicitly tested. When auditing an existing design, it helps to list every distinct text-and-background combination that appears anywhere in the interface first, then run each one through a checker like this individually, rather than assuming that one passing result means the whole design is compliant.
Contrast Checking for Dark Mode
Dark mode interfaces need their own set of contrast checks rather than an inverted assumption that whatever worked in light mode will work in reverse. A text color that passed comfortably at 6:1 on a white background can land at a very different ratio against a dark gray or near-black background, since the luminance math depends on the specific pair, not just on which color is "the text" and which is "the background." A common mistake is using pure white (#FFFFFF) text on a dark background that isn't actually pure black, softer near-black tones like #121212 are popular in dark mode design because pure black can feel harsh, but this shift changes the resulting ratio and should be re-verified rather than assumed. Whenever a design system defines separate light and dark themes, treat each theme's text-and-background pairings as an entirely separate contrast check, since passing in one mode says nothing about the other.
Frequently Asked Questions
Which standard should I aim for?
AA is the widely accepted baseline for most websites and is what most accessibility audits check against. AAA is stricter and often reserved for content where readability is especially critical, like government or healthcare sites.
Does this work for any color format?
Enter colors as hex codes (like #2A2E5A) in the text field, or use the color picker swatch next to it, both stay in sync automatically.
What's the practical difference between AA and AAA?
AA is the legal and industry baseline referenced by most accessibility laws and audits, requiring 4.5:1 for normal text. AAA requires 7:1, noticeably higher, and is genuinely hard to hit with lighter brand colors, most production websites target AA and treat AAA as a bonus where it's easy to achieve.
Does a passing ratio guarantee my text is readable for everyone?
No. Contrast ratio is necessary but not sufficient, it ignores font weight, letter spacing, and font choice, and it doesn't account for every form of visual impairment. Treat a passing ratio as a solid baseline, not a complete accessibility guarantee.
Do disabled buttons and placeholder text need to pass contrast checks?
WCAG technically exempts disabled controls, since they carry no interactive meaning, but placeholder text inside an active input field is a common failure point and should generally still meet AA, since users do read it as content.
Why does large text get a lower required ratio than normal text?
Larger characters have thicker strokes and more surface area per letter, which makes their shapes distinguishable at lower contrast levels. WCAG defines large text as 18pt or larger, or 14pt bold or larger, and lowers the bar accordingly to 3:1 for AA.