Contrast Checker
Check whether text, icons, buttons, input borders, and interface states stay readable on their backgrounds. Enter a foreground and a background color and the tool reports the WCAG contrast ratio, AA / AAA results for normal and large text, UI component AA, transparent color flattening, recommended foreground colors, fix candidates, and copy-ready CSS or audit notes. Everything runs in the browser, so unreleased brand colors and confidential design files stay safe. It fits design review, component QA, dark mode tuning, brand color rollout, and accessibility remediation.
- Reports normal text AA, AAA, large text, and UI component results together, so a single score does not mask the real use case
- Supports HEX, RGB, HSL, HWB, Lab, LCH, OKLab, and OKLCH inputs, ready for design files and DevTools values
- Flattens semi-transparent foregrounds or backgrounds first, so the ratio matches what users actually see
- When a pair fails, offers a recommended baseline color plus generated AA and AAA foreground candidates
- Copy color declarations and a complete audit report in one click for PRs, design reviews, and accessibility tickets
color: #111827; background-color: #ffffff;
Overview
From a color pair to a decision you can take back into the codebase, the whole flow happens in one panel. Each check covers multiple WCAG dimensions and ships with actionable fixes, so a single score never hides the real use case.
- 01
WCAG AA and AAA result matrix
Normal text AA, AAA, large text, and UI component results sit side by side so no single number causes a pair to be approved for the wrong context.
- 02
Multi-format color input
Paste HEX, RGB, HSL, HWB, Lab, LCH, OKLab, or OKLCH directly without normalizing the syntax first.
- 03
Automatic transparent color flattening
When alpha is present, the tool composites against the effective background first, so the ratio matches floating overlays, semi-transparent buttons, and glass-like cards.
- 04
Recommended text color
Compares black and white against the current background and returns the safer baseline foreground for quick decisions or emergency fixes.
- 05
Compliant candidate generation
If the current pair fails, the tool searches along the lightness axis to find the nearest AA and AAA foregrounds, so the brand hue stays intact while accessibility improves.
- 06
Copy-ready CSS and report
Copy color and background-color declarations for implementation, or copy a complete contrast report for PR descriptions, QA tickets, and accessibility remediation logs.
- 07
Common interface presets
Built-in pairs cover body copy, muted text, primary, success, and danger buttons, warning badges, links, and dark mode text as quick reference points.
- 08
Scenario-aware check target
Switch between normal text, large text, and UI component targets to apply the right threshold. The result panel updates immediately, so a 4.5:1 rule is never accidentally used on a button border.
How to use
The flow is intentionally short. It fits into design walk-throughs, component QA, ticket-driven fixes, or quick browser debugging, and the results can be taken straight back into the project.
- 01
Put the text, icon, or control color into the foreground field, and put the surrounding surface color into the background field.
- 02
Choose the check target: normal text for body copy, large text for large labels and headings, and UI component for borders, icons, or control states.
- 03
Read the contrast ratio and the WCAG result matrix to see which AA and AAA targets the pair satisfies.
- 04
If the pair fails, try the recommended foreground; when you want to preserve the brand hue, generate an AA or AAA candidate instead.
- 05
Copy the CSS into your stylesheet, or copy the full contrast report into a PR description, design review, QA note, or accessibility remediation log.
Details
The output is written to be discussed, reproduced, and codified into a design system, not just glanced at as a single score.
- Shows Normal Text AA, AAA, Large Text AA, AAA, and UI Component AA together so a color pair is judged in context
- Displays flattened calculation colors for translucent overlays, glass-like cards, semi-transparent buttons, and dark mode layers
- Swaps foreground and background with one action for inverse buttons, selected states, reversed labels, and dark mode variants
- Reports include the foreground, background, contrast ratio, and every WCAG result, ready for documentation and team workflows
- Built-in interface presets provide quick reference points for body text, muted text, links, buttons, badges, and dark mode text
- The active check target updates pass and fail status instantly, so the wrong threshold is not applied to small body text
- Pairs naturally with color conversion and palette generation to move from normalized values to a stable, accessible color scale
- All parsing, flattening, and contrast calculation runs locally, suitable for unreleased brand colors and confidential design files
- Result messages distinguish body-text-safe, large-text-only, UI-component-only, and not recommended pairs to avoid accessibility misuse
- AA and AAA candidates are tuned along the lightness axis to preserve the brand hue, which makes them more useful for tokenization than blunt black or white fallbacks
Use cases
Contrast checks deliver the most value before a color pair freezes into CSS. The closer they happen to color selection, the cheaper the conversation, and the less likely accessibility issues will resurface after launch.
-
Pre-handoff design checks
Validate body copy, headings, buttons, links, and status labels before a visual design moves into implementation, so engineering does not inherit hidden accessibility debt.
-
Component library QA
Audit Button, Input, Badge, Alert, Tabs, and similar components across default, hover, focus, disabled, selected, and error states, then bake readability into the component spec.
-
Dark mode color tuning
Check body text, secondary labels, borders, and icons on dark surfaces, confirming that the lightness ladder is spread enough and that accent colors stay legible.
-
Brand color rollout
Before applying a brand color to buttons, links, or emphasis, confirm whether it meets contrast requirements and decide whether to prepare a tonal scale around it.
-
Accessibility issue remediation
Reproduce low-contrast issues raised by Lighthouse, axe, manual QA, or users, and document the chosen fix so the underlying decision is captured, not just patched.
-
Reading-heavy content pages
Improve readability for blogs, documentation, help centers, product pages, and long forms where sustained reading is the dominant interaction.
-
Landing page and campaign checks
Review hero copy, CTA buttons, pricing labels, and promotional banners where visual treatments can quietly erode text legibility.
-
Admin dashboard theme maintenance
Keep tables, filters, status indicators, sidebars, and analytics cards aligned to one contrast baseline instead of letting each module drift independently.
-
Data visualization palette alignment
Share a contrast baseline across chart series colors, status colors, and supporting labels so legends and data points stay equally readable.
-
Email and exported asset verification
Email templates, PDF reports, and printed materials run through different rendering pipelines; validating contrast first reduces rework once colors are committed downstream.
See also
When colors arrive from design files, screenshots, or legacy CSS in mixed formats, normalize them in Color Converter first and then bring the pair back here. When the same color keeps failing across many states, build a cleaner scale in Palette Generator instead of patching one-off replacement colors across the interface.
Contrast terms explained
These terms show up in accessibility audits, design system documentation, and frontend review notes. Sharing the same definitions makes it easier to discuss why a color pair fails, rather than relying on phrases like "it looks fine to me".
-
Contrast ratio
WCAG measures contrast from 1:1 to 21:1. A ratio of 1:1 means almost no difference, while 21:1 is the highest contrast, typically pure black on pure white.
-
Relative luminance
Contrast is not a raw comparison of RGB numbers. WCAG converts sRGB values into relative luminance and then derives the ratio between the lighter and darker color.
-
WCAG AA
The baseline accessibility target used by most websites and web apps. Normal text needs at least 4.5:1, while large text and UI components typically need 3:1.
-
WCAG AAA
A stricter target. Normal text needs 7:1, which suits long-form reading, public services, education content, documentation, and reading-heavy interfaces.
-
Normal text vs. large text
Normal text covers typical body copy, labels, and helper text. Large text usually means 18pt regular or 14pt bold and above, which is easier to perceive and therefore allowed a lower threshold.
-
UI component contrast
Button boundaries, input outlines, icons, selected states, and error indicators also need to be recognizable, even when they are not text.
-
Transparent color flattening
Colors written with alpha, including rgba, hsla, and OKLCH alpha values, depend on the surface beneath. Flattening first yields a result that matches the rendered page.
-
OKLCH and perceived lightness
OKLCH lightness tracks human perception more predictably than HSL, which makes it useful for building accessible color scales, dark mode palettes, and brand color systems.
Best practices
Contrast checks pay off the most when they are part of the design and development process rather than a last-minute fix. The practices below have held up across many product shapes; pick the ones that match your context.
- Make Normal Text AA the baseline for body copy, labels, helper text, and error messages, and move reading-heavy areas toward AAA where it makes sense
- Do not rely on low contrast alone to signal a disabled state; combine contrast with opacity, icons, labels, or interaction behavior
- In dark mode, adjust the lightness ladder before turning up saturation. Saturation alone rarely fixes readability
- Check buttons, links, and status indicators in default, hover, focus, selected, error, and disabled states, not just one static screenshot
- Validate translucent overlays, glass-like cards, and floating panels against their actual page background, not a generic surface color
- Promote approved combinations into design tokens such as text-primary, text-muted, surface-card, and border-subtle, so they stop being one-off decisions
- When a brand color fails, build compliant tonal steps instead of choosing arbitrary near-matches on different pages
- Add contrast checks to design review, pull request checklists, and release QA so regressions surface earlier and cost less to fix
Limitations
Color contrast is important, but it is only one part of interface accessibility. Treat the result as a strong signal, not a final verdict, and always pair it with real pages, real devices, and a full accessibility review.
- Passing WCAG contrast does not guarantee full accessibility; semantic structure, keyboard access, focus visibility, error handling, and screen reader behavior still need review
- Text over images, videos, complex textures, or gradients should be sampled from the real page region; a single background color is only an approximation
- Generated AA and AAA candidates are useful for quick exploration, but final colors should be reviewed against brand rules, theme scales, and visual hierarchy
- Different displays, browsers, color management settings, and ambient light can shift perceived readability; important pages should be reviewed on real devices
- The tool evaluates the colors you enter and does not automatically inspect CSS variables, Tailwind config, or design token sources
- APCA and WCAG 2.x use different contrast models. This tool currently reports WCAG 2.x contrast ratios
- Motion, animated backgrounds, and text over moving video need to be observed while playing; a static ratio cannot fully capture those experiences
FAQ
Questions that come up most often when teams use contrast checking in day-to-day work, accessibility compliance, and cross-functional collaboration, from onboarding to thresholds, fix strategies, and limits.
What problem does a color contrast checker solve?
It confirms whether text, icons, and controls remain readable against their background, which is essential during design review, frontend development, and accessibility remediation, and it gives you a clear direction for any fix.
Why is 4.5:1 required for normal text AA?
WCAG 2.x defines 4.5:1 as the minimum contrast ratio for regular body text. It is calculated from relative luminance, not subjective opinion, which gives teams a stable shared standard.
When should I target AAA?
AAA is appropriate for long-form reading, public-service sites, education content, documentation, and product areas where readability is especially important. Most interfaces start with AA as the baseline.
Why does large text pass at 3:1?
Large or bold text is easier to perceive, so WCAG allows a lower threshold. Thin type, busy backgrounds, or small screens may still require stronger contrast.
What does UI Component AA check?
It applies to non-text elements such as button boundaries, input outlines, icons, selected states, and error indicators, which is where many form and admin UI issues actually live.
Do transparent colors affect the result?
Yes. Semi-transparent foregrounds or backgrounds depend on the surface underneath. This tool flattens colors first and then calculates contrast from the effective result.
Why can a design look readable but fail contrast?
Typeface, weight, surrounding elements, brightness, and design-tool rendering all affect perception. The contrast ratio gives the team a stable, reproducible standard instead.
How does OKLCH help with accessible color design?
OKLCH lightness behaves more predictably for human perception, which makes it easier to build accessible color scales for themes, dark mode, and brand systems.
Is recommending black or white too limited?
Black and white provide quick baseline checks. For finished UI, treat the generated AA or AAA candidate as a starting point and fit it into the brand color scale.
Can I use the report in team workflows?
Yes. The report includes the foreground, background, ratio, and each pass and fail result, which makes it useful for PR descriptions, QA notes, design reviews, and accessibility tracking.
Is any color data uploaded?
No. Parsing, flattening, and contrast calculation run locally in the browser, so unreleased brand colors and confidential design files stay private.
What should I check after contrast passes?
Review focus visibility, keyboard navigation, form error messaging, ARIA and semantic HTML, dynamic state feedback, and screen reader behavior. Contrast is one part of a larger picture.
Does this tool support APCA?
It reports WCAG 2.x contrast for now. If your project requires APCA, you can keep this tool as a baseline check and use a dedicated APCA tool for the secondary review.
How do I handle text on gradient or image backgrounds?
Sample the lightest and darkest regions of the background separately and check each pair. If both edges sit just under the threshold, consider adding a darker scrim or moving the text to a calmer area.
Related tools
Chain the contrast checker with color conversion, palette generation, and the gradient generator to move from "we picked a color pair" to "we shipped accessible design tokens", so readability lives in the codebase, not just in review comments.