Free Contrast Checker (WCAG) Online
Check color contrast ratios against WCAG AA and AAA standards. Ensure accessibility compliance.
Ad space
Ad space
How to use the Contrast Checker (WCAG)
- 1
Open the Contrast Checker (WCAG) tool
- 2
Enter your data or upload your file
- 3
Adjust settings if needed
- 4
Get instant results
- 5
Download or copy your output
Frequently asked questions
Is the Contrast Checker (WCAG) free?
Yes, our contrast checker (wcag) is 100% free with no limits, no signup, and no watermarks.
Do I need to create an account?
No. You can use the contrast checker (wcag) without any registration. Just open it and start using it.
Is my data safe?
Yes. Any files you upload are automatically deleted after 5 minutes. We never store, share, or access your data.
Does this work on mobile?
Yes. The contrast checker (wcag) is fully responsive and works on phones, tablets, and desktops.
Is there an API for this?
Yes. All our tools are available as API endpoints for developers. Check our API documentation for details.
Contrast Checker (WCAG): Test If Your Text Passes AA or AAA
A contrast checker measures how easy a piece of text is to read against its background by computing the mathematical contrast ratio between the two colors and comparing it against the thresholds set by the Web Content Accessibility Guidelines (WCAG). Enter a foreground (text) color and a background color, and this tool returns a precise ratio — anywhere from 1:1 (no contrast at all, identical colors) up to 21:1 (pure black text on pure white, the maximum possible under the WCAG formula) — along with a clear pass or fail against each official threshold. Nothing is uploaded; the comparison runs as JavaScript in your browser the instant you change either color.
This matters beyond aesthetics. Low-contrast text is genuinely difficult or impossible to read for people with low vision, color vision deficiencies, or anyone using a phone screen in bright sunlight, and WCAG conformance is frequently a hard legal or contractual requirement for government sites, educational platforms, and any organization subject to accessibility regulations. A contrast checker turns "does this look readable to me" into an objective, defensible number.
How to Check Contrast with This Tool
The workflow is built to let you tune colors and see the result update live:
- Set the text color using the color swatch picker or by typing a hex value directly into the field labeled for foreground/text color.
- Set the background color the same way, in the adjacent field.
- A live preview panel immediately renders sample heading text, body-sized paragraph text, and small text in your chosen colors against your chosen background, so you can judge readability visually as well as numerically.
- The contrast ratio appears as a large number (for example, 4.53:1), color-coded and backed by a proportional bar showing how far that ratio sits along the 1:1-to-21:1 range.
- Below that, four result cards show pass/fail status for AA Normal Text, AA Large Text, AAA Normal Text, and AAA Large Text, each labeled with its exact minimum ratio requirement.
- A swap button lets you instantly flip foreground and background, which is useful for checking both directions of a two-tone design (light text on a dark card, then the reverse) without retyping either value.
Because every one of those steps runs locally, there's no lag between adjusting a color and seeing whether it passes — you can nudge a hex value by a shade and immediately see the ratio and pass/fail status respond.
How the Contrast Ratio Is Actually Calculated
The number this tool reports is not a simple average of the two colors' RGB brightness — that shortcut produces a ratio that doesn't match how the human eye actually perceives contrast, and it's not what WCAG specifies. The real formula, which this checker implements exactly, works in three steps:
- Linearize each sRGB channel. Every red, green, and blue value (0-255) is first divided by 255, then run through a piecewise formula: values at or below 0.03928 are divided by 12.92, and everything above that is raised through ((channel + 0.055) / 1.055) ^ 2.4. This "gamma correction" step exists because standard sRGB displays don't render brightness linearly, and skipping it produces measurably wrong results for mid-range colors.
- Compute relative luminance. The three linearized channels are combined with fixed weights that reflect human eyes' differing sensitivity to each color: L = 0.2126 × R + 0.7152 × G + 0.0722 × B. Green contributes far more to perceived brightness than blue, which is why this weighting — not a plain 1/3-1/3-1/3 average — is required.
- Divide the lighter luminance by the darker, both offset by 0.05. The final ratio is (L_lighter + 0.05) / (L_darker + 0.05), where L_lighter and L_darker are whichever of the two colors' luminance values is higher and lower. The 0.05 offset accounts for ambient light scatter reaching the eye even from a "black" screen area, and it's the reason the ratio for pure black versus pure white lands at exactly 21:1 rather than some other number.
That third step is worth double-checking against a known anchor: black (#000000) against white (#FFFFFF) computes to a relative luminance of 0 for black and 1 for white, giving (1 + 0.05) / (0 + 0.05) = 21, i.e. 21:1 — the highest contrast ratio the formula can produce, and the reason 21:1 shows up so often as the reference maximum in accessibility documentation. A naive RGB-average approach would not reproduce this exact number, and would also misjudge colors of similar overall brightness but different hue — which is precisely why WCAG specifies the gamma-corrected relative-luminance method instead.
The WCAG Thresholds Explained
WCAG 2.x defines two conformance levels, each with a lower bar for large text:
| Level | Normal text | Large text | What "large" means |
|---|---|---|---|
| AA (minimum) | 4.5:1 or higher | 3:1 or higher | 18pt (24px) regular weight, or 14pt (18.66px) bold, or larger |
| AAA (enhanced) | 7:1 or higher | 4.5:1 or higher | Same large-text definition as AA |
AA is the level most legal and organizational accessibility requirements reference, including many jurisdictions' interpretation of ADA compliance for web content and the EU's EN 301 549 standard — it represents the minimum contrast most designers should treat as non-negotiable for body copy, form labels, and any text carrying meaning. AAA is a stricter, "enhanced" level intended for content where readability matters even more, such as text aimed at users with significant vision loss; it's encouraged where practical but isn't always achievable with brand colors that have strict hue and saturation requirements, so plenty of otherwise well-designed sites intentionally target AA rather than AAA. The large-text exception exists because bigger, heavier glyphs remain legible at lower contrast than small body text does — the same 3:1 or 4.5:1 ratio that would fail for a paragraph is acceptable for a large, bold heading.
One nuance worth knowing: these thresholds apply to text against its immediate background, not to decorative graphics or logos, and WCAG has a separate (lower) 3:1 requirement for non-text elements like icons and input field borders that convey information — this tool is built specifically around the text-contrast formula and its AA/AAA text thresholds.
Real Scenarios Where Contrast Checking Catches Problems
A few situations come up constantly for anyone building or reviewing interfaces:
- Light-gray body text on white backgrounds. A popular but risky design trend uses medium-gray text (something like #999999) on a white card for a "softer" look — this frequently fails AA's 4.5:1 requirement for normal text, and checking it before shipping avoids a readability complaint or an accessibility audit finding later.
- Brand colors used as text color. A vibrant brand blue or teal that looks great as an accent might not have enough luminance difference from a white or light background to pass as body text, even though it reads fine as a button or icon color at a larger size.
- Dark-mode interfaces. Flipping a design to a dark background doesn't automatically preserve contrast ratios — a text color tuned to look good on white can land at a very different ratio against a dark navy or near-black background and needs its own check.
- Overlay text on photographs or gradients. Text placed over a hero image or a color gradient needs to be checked against the actual pixel colors it sits on, not just an assumed background — sampling the darkest and lightest regions the text might overlap is a practical way to stress-test it here.
- Accessibility audits and compliance reviews. Teams preparing for a Section 508, ADA, or WCAG conformance review commonly run every text/background color pairing in a design system through a contrast checker as one of the first, fastest checks, since it catches a large share of common failures before more involved manual testing begins.
Contrast Checker vs. Other Ways to Verify Accessibility
Checking contrast ratios is one piece of a broader accessibility practice, and it's worth knowing how it fits alongside other tools:
- Browser DevTools accessibility panels. Chrome and Firefox both surface a contrast ratio directly in their element inspector when you select text, which is convenient for spot-checking a live page but slower than testing color combinations before they're ever built.
- Full accessibility audit tools. Automated scanners like axe or Lighthouse check contrast as one of dozens of WCAG success criteria (alt text, keyboard navigation, ARIA labeling, and more) across an entire page or site — the right choice for a comprehensive audit, but overkill when you just need to test two colors before finalizing a design.
- Design software plugins. Figma and similar tools have contrast-checking plugins that overlay a pass/fail badge directly on design layers, useful for catching issues during the design phase itself rather than after handoff to development.
- Manual calculation. The relative-luminance formula above can be computed by hand or in a spreadsheet, but doing it correctly requires implementing the gamma-correction step precisely — an easy place to introduce a subtle bug that produces plausible-looking but wrong ratios.
- The API. For teams that want to enforce contrast requirements automatically — as part of a design-token build step, a CI check on a component library, or a linting rule — this checker's contrast logic is available as a metered API endpoint that accepts a foreground and background hex color and returns the exact ratio plus AA/AAA pass/fail flags; see the API documentation for details.
What's a good contrast ratio for body text on a website?
Aim for at least 4.5:1, which is the WCAG AA threshold for normal-sized text and the level most accessibility guidelines and legal standards reference as the baseline. Going higher, toward AAA's 7:1, gives extra headroom for users with lower vision but isn't strictly required for most content.
Does a larger font size really need less contrast to pass?
Yes. WCAG defines "large text" as 18pt (24px) regular weight or 14pt (18.66px) bold or larger, and permits a lower ratio for it — 3:1 for AA, 4.5:1 for AAA — because bigger, heavier strokes remain legible at contrast levels that would be too low for small body copy.
Why is black on white exactly 21:1 and not some other number?
Because the WCAG formula's relative luminance for pure black is 0 and for pure white is 1, and the ratio formula adds a fixed 0.05 to each side before dividing: (1 + 0.05) / (0 + 0.05) works out to exactly 21. That 0.05 offset — meant to model ambient light reaching the eye even from a fully black display area — is also why the maximum possible ratio under this formula is capped at 21:1 rather than being unbounded.
Is a contrast ratio of 3:1 ever acceptable for normal-sized text?
No, not under WCAG AA or AAA — 3:1 is only sufficient for large text (or for non-text UI elements like icons and borders, which fall under a separate WCAG success criterion). Normal-sized body text needs at least 4.5:1 to meet AA.
Can two colors with very different hues still pass a contrast check?
Yes — the WCAG formula only cares about relative luminance, not hue, so a saturated orange and a deep blue can pass just as easily as two grayscale tones, provided their computed luminance values are far enough apart. Conversely, two very different-looking hues can still fail if their luminance happens to be similar.
Related Color Tools
If a color combination fails, the color shade/tint generator can produce a lighter or darker variant of the same hue to test against your background instead of guessing at a replacement by eye. The color converter is useful for translating a passing hex value into the RGB or HSL format your codebase actually uses. And when you're choosing an entire palette rather than a single pairing, the color palette generator can build out a full scheme that you can then run each combination from through this checker before finalizing it.
Ad space
Related tools
Ad space