WCAG

Color Contrast Checker

Check WCAG contrast ratio

Color & Design

🔒 100% client-side — your data never leaves this page

Maintained by ToolsKit Editorial Team•Updated: April 7, 2026•Reviewed: April 7, 2026

Editorial Policy/Privacy/Report issue

English version/Chinese version

Page mode

Colors

Quick CTA

Enter foreground and background colors first to inspect contrast ratio and WCAG level immediately; adjustment suggestions stay in Deep.

ForegroundBackground

Contrast Result

Contrast17.40:1

WCAG AA (normal)PASS

WCAG AA (large)PASS

WCAG AAA (normal)PASS

🔒 100% client-side

Next step workflow

Generate color palette Convert HEX/RGB/HSL Encode CSS snippets

Page reading mode

Deep expands pitfalls, recipes, snippets, FAQ, and related tools when you need troubleshooting or deeper follow-through.

About this tool

Check color accessibility contrast between foreground and background colors with real-time WCAG ratio calculation. The tool evaluates AA and AAA thresholds for normal and large text, helping designers and developers ship readable interfaces that meet accessibility standards.

Direct Answers

Q01

Why check contrast before shipping UI copy?

Because colors that look fine in isolation can still fail readability when paired in real text usage.

Q02

Does passing one contrast check mean the whole palette is safe?

No. Each foreground-background pairing still needs to be evaluated separately.

Compare & Decision

Palette aesthetics vs readable contrast

Palette aesthetics

Use it when exploring brand or visual mood.

Readable contrast

Use it when text readability and accessibility matter.

Note: A pleasing palette is valuable, but readable contrast is what makes UI usable.

Palette-level contrast check vs component-state contrast check

Palette-level

Use in early visual exploration to quickly eliminate unsafe pairs.

Component-state level

Use before release to validate real UI states and typography.

Note: Production accessibility quality depends on state-specific checks, not palette averages.

Manual sample testing vs tokenized design-system enforcement

Manual testing

Use for prototypes and one-off microsites.

Design-token enforcement

Use for multi-team product surfaces with shared UI kits.

Note: Token enforcement prevents regressions at scale.

Component-level spot checks vs token-level systematic checks

Token-level checks

Use for scalable design systems and theme variants.

Component-only checks

Use for one-off prototypes with no shared token lifecycle.

Note: Token-level quality gates prevent repeated downstream accessibility regressions.

WCAG AA baseline vs AAA target

AA baseline

Use for most product UI with broad practicality.

AAA target

Use for accessibility-first products or critical reading surfaces.

Note: AA is practical minimum, AAA is beneficial where readability is mission-critical.

Failure Input Library

Only default state tested, interaction states skipped

Bad input: Checking contrast for normal button text but not hover, disabled, or focus states.

Failure: Design passes review yet fails accessibility once real UI states are exercised.

Fix: Test all critical state pairings, not just the default visual snapshot.

Semi-transparent overlays evaluated with wrong final colors

Bad input: Running contrast check on base colors without compositing alpha over actual background.

Failure: Measured ratio looks compliant, but rendered screen is still hard to read.

Fix: Compute/check the final rendered foreground-background colors after alpha blending.

Checking only primary buttons and skipping text variants

Bad input: Contrast audit includes CTA buttons but excludes muted text states.

Failure: Low-contrast secondary text ships to production unnoticed.

Fix: Audit semantic token pairs across all state variants, not only hero components.

Opacity overlays not considered

Bad input: Contrast tested on pure brand color but production uses 70% opacity overlay.

Failure: Real rendered contrast fails accessibility checks.

Fix: Test contrast using final composited colors from actual UI state.

Only default state audited

Bad input: Button contrast checked for normal state but not hover/disabled states.

Failure: Interactive states become unreadable for users.

Fix: Audit all component states including hover, active, disabled, and focus.

Scenario Recipes

Validate a text-on-background pair

Goal: Check whether a foreground and background color combination is readable before using it in UI.

Paste the foreground and background colors.
Review the contrast ratio and pass or fail output.
Adjust the colors and retest until the pairing is safe for the intended text size.

Result: You can avoid shipping visually pretty but hard-to-read color pairings.

Design-token accessibility gate before UI release

Goal: Validate contrast pairs in token library before components reach staging.

Export candidate foreground/background token pairs from design system.
Run WCAG contrast checks and classify pass/fail by usage context.
Block release for failing semantic tokens and patch in token source.

Result: Accessibility defects are removed before component-level QA starts.

Accessible theme rollout audit

Goal: Validate text and UI contrast across light and dark themes before release.

List all semantic color pairs used by core components.
Check each pair against target contrast threshold.
Patch failing tokens and rerun visual regression snapshots.

Result: Theme updates ship with fewer accessibility regressions.

Design handoff gate for marketing pages

Goal: Prevent low-contrast hero and CTA text combinations in campaign assets.

Review planned foreground/background pairs from mockups.
Score each pair with contrast checker before implementation.
Approve only combinations meeting agreed accessibility threshold.

Result: Campaign pages remain visually strong and readable.

Quick Decision Matrix

Pre-release accessibility gate for text-heavy UI

Recommend: Validate each real text/background pair with target size/weight context.

Avoid: Avoid approving palette-level ratios without component-level checks.

Early visual exploration with brand colors

Recommend: Generate palette options first, then run contrast screening to shortlist safe pairs.

Avoid: Avoid locking brand color decisions before readability validation.

Multiple product surfaces consume one shared token library

Recommend: Gate contrast at token source before component compilation.

Avoid: Avoid late manual fixes in each product surface separately.

General product UI with mixed visual priorities

Recommend: Enforce WCAG AA for all text and controls.

Avoid: Avoid shipping components that pass only by manual exceptions.

Education, healthcare, or policy-heavy reading pages

Recommend: Target AAA where possible for long-form readability.

Avoid: Avoid decorative color choices that sacrifice legibility.

Failure Clinic (Common Pitfalls)

Testing only one happy-path combination

Cause: Real products often reuse colors across buttons, cards, hints, and body text.

Fix: Validate each important pairing rather than assuming one pass covers everything.

Production Snippets

Contrast sample

txt

#1a1a1a on #ffffff

Practical Notes

Color Contrast Checker works best when you apply it with clear input assumptions and a repeatable workflow.

Conversion strategy

Define source format assumptions before converting, especially encoding and delimiter rules.

Validate a small sample first, then run full conversion to avoid large-scale data cleanup later.

Quality control

Keep one canonical source and treat converted outputs as derived artifacts.

Use diff checks on representative samples to catch type drift or formatting regressions.

Use It In Practice

Color Contrast Checker is most reliable with real inputs and scenario-driven decisions, especially around "Pre-release accessibility gate for text-heavy UI".

Use Cases

When Pre-release accessibility gate for text-heavy UI, prioritize Validate each real text/background pair with target size/weight context..
When Early visual exploration with brand colors, prioritize Generate palette options first, then run contrast screening to shortlist safe pairs..
Compare Palette aesthetics vs Readable contrast for Palette aesthetics vs readable contrast before implementation.

Quick Steps

Paste the foreground and background colors.
Review the contrast ratio and pass or fail output.
Adjust the colors and retest until the pairing is safe for the intended text size.

Avoid Common Mistakes

Common failure: Design passes review yet fails accessibility once real UI states are exercised.
Common failure: Measured ratio looks compliant, but rendered screen is still hard to read.

Frequently Asked Questions

What ratio is required for WCAG AA?

AA requires at least 4.5:1 for normal text and 3:1 for large text.

What ratio is required for WCAG AAA?

AAA requires at least 7:1 for normal text and 4.5:1 for large text.

Can I use shorthand hex values?

Yes. Both 3-digit and 6-digit hex color formats are supported.

Is conversion reversible without data loss?

It depends on formats. Structured conversions are usually reversible, but style details like comments, spacing, or field order may not round-trip exactly.

Does this converter keep my data private?

Yes. Conversion runs entirely in your browser and no content is sent to any backend service.

Why does converted output look slightly different?

Tools may normalize whitespace, quoting style, or numeric formatting while preserving the underlying data meaning.