Contrast Checker
Check if your text and background colors meet WCAG accessibility standards. Our Contrast Checker calculates the contrast ratio and shows pass/fail for AA and AAA levels.
Key features
- Real-time contrast ratio calculation
- WCAG 2.1 AA and AAA compliance check
- Support for normal and large text standards
- Color swap and live preview
Guide
Color contrast accessibility determines whether text on your website is readable by everyone, including people with visual impairments. The Web Content Accessibility Guidelines (WCAG) define specific contrast ratios that text must meet to be considered accessible. Failing to meet these standards means some visitors cannot read your content, and in many jurisdictions, it means your site does not comply with legal accessibility requirements. This guide explains how contrast ratios work, what WCAG requires, and how to fix contrast issues without compromising your design. A contrast ratio compares the relative luminance of two colors on a scale from 1:1 (no contrast, both colors identical) to 21:1 (maximum contrast, pure black on pure white). Relative luminance is a measure of how bright a color appears to the human eye, calculated from the color's RGB values using a formula that accounts for how human vision perceives different wavelengths. Red, green, and blue contribute differently to perceived brightness, with green contributing the most and blue the least. The formula is: L = 0.2126 * R + 0.7152 * G + 0.0722 * B, where R, G, and B are linearized from their sRGB values. The linearization step converts gamma-encoded sRGB values to linear light values by applying a transfer function. The contrast ratio itself is calculated as (L1 + 0.05) / (L2 + 0.05), where L1 is the relative luminance of the lighter color and L2 is the relative luminance of the darker color. The 0.05 value accounts for ambient light. This formula produces the familiar ratio format. For example, pure white has a luminance of 1.0 and pure black has a luminance of 0.0, giving a contrast ratio of (1.0 + 0.05) / (0.0 + 0.05) = 21:1. WCAG defines two conformance levels for contrast. Level AA is the baseline requirement for most websites. Level AAA is a stricter standard that provides better readability. For normal-sized text (under 18pt or under 14pt bold), Level AA requires a contrast ratio of at least 4.5:1 and Level AAA requires 7:1. For large text (18pt and above, or 14pt bold and above), Level AA requires 3:1 and Level AAA requires 4.5:1. These thresholds are based on research into readability for people with moderately low vision, roughly 20/40 acuity, which is the typical vision loss threshold for older adults. The large text exception exists because bigger letters are inherently easier to read. At larger sizes, thicker strokes and wider counters make characters more distinguishable even at lower contrast. This is why headings, hero text, and other large display text can use a 3:1 ratio under AA compliance while body text requires 4.5:1. In CSS terms, 18pt equals 24px at default browser settings, and 14pt bold equals approximately 18.66px bold. If you are unsure whether your text qualifies as large, apply the stricter 4.5:1 ratio to be safe. Non-text elements also have contrast requirements under WCAG 2.1 Success Criterion 1.4.11 (Non-text Contrast). User interface components (buttons, form inputs, focus indicators) and graphical objects (icons, chart elements) that are necessary for understanding content must have at least a 3:1 contrast ratio against adjacent colors. A light gray button border on a white background that falls below 3:1 makes the button hard to identify as a clickable element, particularly for users with low vision. Focus indicators are especially important: keyboard users rely on visible focus styles to navigate, and those focus styles must meet the 3:1 ratio against surrounding content. Color blindness affects approximately 8% of men and 0.5% of women of Northern European descent, with varying prevalence across other populations. The most common form is red-green color blindness (deuteranopia and protanopia), where reds and greens appear similar. Blue-yellow color blindness (tritanopia) is less common. Complete color blindness (achromatopsia) is rare. Contrast ratio calculations based on luminance work independently of color perception because they measure brightness difference, not hue difference. However, relying solely on color to convey information (red for error, green for success) creates problems for colorblind users regardless of contrast ratio. Always provide additional visual cues like icons, text labels, or patterns alongside color coding. Dark mode introduces additional contrast considerations. Many designers create dark themes by simply inverting colors, but this often produces poor results. Pure white (#FFFFFF) text on pure black (#000000) backgrounds creates maximum contrast (21:1), but this level of contrast can cause visual fatigue and halation (a glowing effect around light text on dark backgrounds) for some users. A slightly reduced contrast, like #E0E0E0 on #121212, is more comfortable while still exceeding WCAG AAA requirements. Google's Material Design dark theme guidelines recommend using #121212 as the surface color and reducing text opacity rather than using pure white. Primary text uses 87% opacity, secondary text uses 60%, and disabled text uses 38%. Semi-transparent colors complicate contrast checking. When you use rgba() or hsla() colors with alpha values less than 1, the actual rendered color depends on what is behind it. White text at 70% opacity on a dark background has a different effective contrast than the same text on a light background. When checking contrast for semi-transparent text, you need to calculate the composited color (the actual color the user sees after the transparency is applied against the background). The formula blends the foreground and background based on the alpha value: composited = foreground * alpha + background * (1 - alpha), applied to each channel. Always check the composited result, not the transparent color in isolation. Gradient backgrounds create variable contrast across the text area. If text sits on a gradient that transitions from dark blue to light blue, the contrast ratio differs at the left and right edges of the text. WCAG requires the contrast ratio to be met at every point where text appears. Check the contrast at the weakest point, which is where the background is closest in luminance to the text color. If the gradient ranges from #003366 to #6699CC and your text is white, check the contrast against #6699CC because that is where it will be lowest. For radial gradients, check multiple points across the text area. Image backgrounds present the hardest contrast challenge. Text on photographs or patterned backgrounds will have different contrast at every pixel. The solutions are: place a solid or semi-transparent overlay between the image and text, use a text shadow or outline to ensure legibility, or restrict text to areas of the image with consistent color. A common pattern is a dark gradient overlay on the bottom of a hero image where text appears. The gradient darkens the image enough to create sufficient contrast with white text. For overlays, rgba(0, 0, 0, 0.5) typically brings most images into WCAG AA compliance with white text, but verify with your specific images. Color spaces and contrast calculations are more complex than most tools acknowledge. The standard WCAG contrast formula uses relative luminance in the sRGB color space. This formula has known limitations. It can overestimate the contrast of very dark color pairs and underestimate the contrast of light color pairs. Research has shown that a dark blue text (#00007E) on a black background technically passes WCAG AA but is extremely difficult to read in practice. The APCA (Advanced Perceptual Contrast Algorithm) is a newer approach developed for WCAG 3.0 that accounts for human visual perception more accurately, including the polarity effect (dark text on light backgrounds is perceived differently than light text on dark backgrounds). While WCAG 2.x and its sRGB-based formula remain the current legal standard, APCA provides a more perceptually accurate assessment. The APCA model assigns different contrast requirements based on font size and weight, creating a matrix of minimum contrast values rather than the binary threshold approach of WCAG 2.x. For example, 14px normal weight text needs a higher APCA contrast value than 24px bold text. APCA also handles the polarity issue: light text on dark backgrounds requires different contrast values than dark text on light backgrounds. While APCA is not yet the official standard, understanding it helps you make better contrast decisions, especially in edge cases where WCAG 2.x produces questionable results. Fixing contrast failures typically involves one of three approaches: darkening the text, lightening the background, or both. When adjusting colors, stay within your brand palette by modifying the lightness value in HSL color space rather than changing the hue or saturation. If your brand blue is hsl(210, 80%, 55%) and it fails contrast against white, reducing lightness to hsl(210, 80%, 40%) may pass while remaining recognizably your brand blue. Small lightness adjustments often solve contrast problems without requiring a complete redesign. In the OKLCH color space, these adjustments produce even more perceptually uniform results. CSS custom properties make contrast-aware theming practical. Define your colors as HSL values in custom properties, then create light and dark theme variants that meet contrast requirements. For example: --brand-primary: hsl(210, 80%, 40%) for light theme and --brand-primary: hsl(210, 80%, 70%) for dark theme. Both use the same hue and saturation but different lightness values optimized for their respective backgrounds. This approach scales to entire design systems with dozens of color tokens. You maintain brand consistency while meeting accessibility requirements in every theme. Design system integration is where contrast checking becomes most valuable. Rather than checking individual page elements, define your color tokens and verify that every text-on-background combination in your token system passes WCAG requirements. Document the approved combinations in a contrast matrix that shows which text colors are safe on which background colors. Then when developers build components, they select from pre-approved color pairs and contrast compliance is guaranteed by the system rather than checked per instance. This is how large organizations like Google, Microsoft, and Adobe handle contrast at scale. Building a contrast matrix involves listing all your background colors across the top and all your text colors down the side, then calculating the contrast ratio for each intersection. Mark each cell as AA pass, AAA pass, or fail. This matrix becomes a reference document for your entire team. When a designer specifies a color combination, they can check the matrix instantly. When a developer implements a component, the matrix tells them which color tokens are safe together. Automated testing catches contrast issues early. Tools like axe-core, Lighthouse, and Pa11y scan rendered pages and flag elements that fail WCAG contrast requirements. Integrate these into your CI/CD pipeline so contrast regressions are caught before deployment. The limitation of automated tools is that they cannot evaluate text on images, gradients, or dynamically changing backgrounds. Manual checking with a contrast checker tool remains necessary for these cases. A comprehensive approach uses automated testing for the majority of cases and manual checking for the edge cases that automation cannot handle. Legal compliance drives much of the urgency around contrast accessibility. The Americans with Disabilities Act (ADA) in the United States, the European Accessibility Act in the EU, the Accessibility for Ontarians with Disabilities Act in Canada, and similar laws in other jurisdictions either directly require WCAG compliance or have been interpreted by courts to require it. Lawsuits over web accessibility have increased significantly year over year, with contrast failures being one of the most commonly cited issues. Meeting WCAG AA is the widely accepted legal standard. Organizations in regulated industries (government, healthcare, education, finance) face stricter requirements and more active enforcement. Beyond legal compliance, good contrast is good design. Text that is easy to read converts better, retains visitors longer, and reduces bounce rates. Users reading on phones in bright sunlight, older users with naturally declining vision, users on low-quality monitors with poor color reproduction, and users who are simply tired all benefit from strong contrast. Designing for the edges of human capability (low vision, challenging environments) produces designs that work better for everyone in the center too. Studies have shown that higher contrast text reduces reading time and improves comprehension across all users, not just those with visual impairments. Testing your contrast choices in real conditions means checking on multiple devices, in various lighting conditions, and with actual content rather than placeholder text. A color pair that passes the mathematical contrast check might still be hard to read if the font is thin, the text is small, or the letter-spacing is tight. Contrast ratio is a necessary minimum, not a guarantee of readability. Pair adequate contrast with appropriate font size (minimum 16px for body text), weight (regular or medium, not light or thin), and spacing (line-height of 1.5 or more) for the best results. Common contrast pitfalls include placeholder text in form inputs (often light gray on white, failing contrast requirements), disabled button text (still needs to be distinguishable, even if not meeting full contrast requirements), link text that relies only on color to distinguish it from surrounding text (WCAG requires an additional visual indicator like underline unless the link contrast against surrounding text is at least 3:1), and text over decorative backgrounds where contrast varies by position. Brand color accessibility is a frequent challenge. Marketing teams choose brand colors for emotional impact and visual appeal, not for WCAG compliance. A bright orange brand color (hsl(30, 100%, 50%)) has a contrast ratio of only 2.14:1 against white, far below the 4.5:1 AA requirement for normal text. The solution is creating accessible variants of brand colors. Keep the hue, adjust the lightness. hsl(30, 100%, 35%) is still recognizably orange but passes AA against white at 4.6:1. Create a brand color palette with primary colors for large text and decorative elements (lower contrast acceptable) and adjusted variants for body text, links, and UI components (must pass AA). Data visualization and charts present unique contrast challenges. Each data series in a chart needs to be distinguishable from adjacent series and from the background. With five or more data series, finding colors that all contrast sufficiently with each other and with the background is difficult. Color-blind-safe palettes (like those from ColorBrewer or the Okabe-Ito palette) are designed specifically for this purpose. Beyond color, use patterns, textures, or direct labels to distinguish data series. Line charts can use different dash patterns. Bar charts can use diagonal hatching. Scatter plots can use different shapes. Contrast in different lighting environments varies dramatically. A color pair that is comfortably readable in a dim office becomes barely visible in direct sunlight. Mobile users frequently encounter bright outdoor conditions. High contrast ratios provide a buffer against environmental factors. A pair at exactly 4.5:1 (the AA minimum) is legible in controlled conditions but may fail in bright sunlight. Targeting 5:1 or 6:1 provides margin that accounts for real-world viewing conditions. For critical UI elements (navigation, calls to action, error messages), err on the side of higher contrast. Color management and device differences affect how users perceive contrast. An sRGB color on a wide-gamut display (P3 or Adobe RGB) may appear slightly different than intended. Cheap TN panel monitors display colors differently than IPS or OLED screens. Screen brightness settings change perceived contrast. Blue light filters and night mode tint the display warm, reducing the perceived contrast of cool colors. None of these factors change the calculated WCAG ratio, but they affect the actual visual experience. Testing on multiple devices and in multiple conditions catches problems that mathematical calculations miss. Contrast requirements for text embedded in images are the same as for live text. If your hero image contains text baked into the image file (not HTML text), that text still needs to meet WCAG contrast requirements. The difference is that you cannot adjust image text with CSS, so the contrast must be verified in the image editing tool before export. Social media preview images (og:image) often contain text that should be legible, though these are not formally covered by WCAG since they appear on third-party platforms. Contrast in typography goes beyond just foreground and background colors. The perceived contrast of text depends on font weight, font size, letter spacing, and line height. Thin fonts (300 weight and below) need higher contrast ratios than the same text in regular or bold weight because the thinner strokes are harder to distinguish from the background. The WCAG specification does not account for font weight in its thresholds (only size), so a technically passing ratio can still produce unreadable text if the font is too thin. For body text, use regular (400) or medium (500) weight at minimum. Reserve light and thin weights for large headings where the size compensates for the reduced stroke visibility. Systematic contrast auditing across a large website requires a combination of automated tools and manual review. Run automated scans (axe-core, Lighthouse) to catch the low-hanging fruit: hardcoded colors that fail ratios. Then manually review dynamic content, user-generated content areas, interactive states (hover, focus, active, disabled), error and success messages, tooltip text, and any area where color is determined at runtime. Create a recurring audit schedule: quarterly for large sites, monthly during active development. Track the number of contrast issues over time to measure progress. The contrast checker tool lets you input any two colors and instantly see the contrast ratio, WCAG AA and AAA pass/fail status for both normal and large text, and a visual preview of the combination. Use it during the design phase to validate color choices before they reach development, during code review to verify implemented colors match the design, and during accessibility audits to identify and fix existing issues. The tool accepts hex, RGB, and HSL color values and shows the computed luminance for each color alongside the ratio.
Frequently asked questions
What contrast ratio is needed for WCAG AA?
WCAG AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18px+ or 14px+ bold).
What is the difference between AA and AAA?
AAA is stricter: 7:1 for normal text and 4.5:1 for large text. AA is the minimum recommended standard.
