ตัวตรวจสอบคอนทราสต์สี

Check WCAG color contrast in your browser

This color contrast checker measures the WCAG contrast ratio between a text and background color and tells you instantly whether the pair passes AA and AAA for normal text, large text, and UI components. Type a hex value, edit the RGB or HSL fields, drag the lightness slider, or use the eyedropper to sample any color on your screen — the ratio, the pass-fail matrix, and the live preview all update as you type.

It works like the tools designers already trust — the same WCAG math behind WebAIM and Adobe Color — but adds a live readable preview, an APCA (WCAG 3) score, and a one-click fix for failing pairs. Everything runs locally in JavaScript: your colors never leave your device, and no account is needed.

WCAG AA and AAA thresholds explained

The WCAG contrast ratio runs from 1:1 (two identical colors) to 21:1 (black on white). Level AA — the bar most laws like the ADA and Section 508 require — needs 4.5:1 for normal text and 3:1 for large text. Level AAA raises that to 7:1 and 4.5:1. Large text means 18pt (24px) and up, or 14pt (roughly 18.66px) and up when bold.

The pass-fail matrix breaks every threshold out separately, so you can see at a glance that a gray like #767676 on white squeaks past AA body text at 4.54:1 but falls short of the 7:1 needed for AAA. If your product team needs to satisfy legal compliance (ADA, EN 301 549, Section 508), AA is the bar to clear. AAA is worth pursuing in reading-heavy interfaces where low-vision users are a priority.

Preview, fix, and ship accessible color pairs

Numbers only tell half the story, so the live preview renders real headings, body copy, small print, and a sample button and chip in your exact colors — see the readability, do not just read the ratio. When a pair fails, the 'Make it pass' suggester keeps your hue and saturation and nudges the lightness to the nearest color that clears your chosen level (AA, AA large, or AAA), then applies it in one click. You can adjust the text or the background, whichever you prefer.

The pairwise grid accepts a full palette and shows which color combinations pass at a glance — useful when building a design system where every foreground and background pairing needs to be safe. Instead of testing dozens of pairs one at a time, you paste your palette once and see the full matrix instantly.

APCA: a preview of WCAG 3 contrast

Alongside the classic ratio, this checker shows an APCA Lc score — the perceptual contrast metric proposed for WCAG 3. APCA models how the eye actually reads light-on-dark versus dark-on-light text and factors in font weight, so it catches readability problems the WCAG 2 ratio sometimes misses. Rough targets: Lc 75+ for body text, Lc 60+ for large text, Lc 45+ for large headings.

WCAG 3 is still in draft and has not replaced WCAG 2.2, so compliance today means meeting the 4.5:1 and 3:1 thresholds. Showing APCA alongside the current ratios lets you future-proof your palette without waiting for the spec to finalize. If your Lc score is already in the recommended range, you are likely to stay compliant when WCAG 3 eventually becomes the reference standard.

Non-text contrast for icons and UI components

Contrast is not only about text. WCAG 2.1 SC 1.4.11 requires 3:1 contrast for the boundaries of interactive components — input borders, focus indicators, toggle states — and for meaningful icons and graphics. The matrix includes a dedicated UI and graphics check at 3:1 so you can confirm a button outline or icon is visible, not just the label inside it.

This is one area where many teams fail audits without realizing it. A light-gray input border (#D1D1D1 on white is 1.4:1) is a common WCAG 2.1 violation even when all the text on the page passes. Checking your UI components here takes seconds and prevents surprises in a formal audit.

How this compares to WebAIM, Adobe Color, and Chrome DevTools

WebAIM's contrast checker at webaim.org is the most widely cited free accessibility tool and uses the same WCAG 2 formula as this one. It does not show APCA, has no live text preview, cannot auto-fix failing pairs, and has no pairwise palette grid for testing multiple color combinations at once.

Adobe Color's Accessibility Tools section shows AA/AAA pass-fail and includes a color blindness simulator, but it requires a free Adobe account to save your work, and it cannot auto-suggest a passing color. The mobile interface can be cumbersome.

Chrome DevTools has a contrast ratio badge in the Elements panel color picker that works for in-browser checks — but only inside DevTools, so you cannot share a link to a specific color pair or use it outside a browser session.

This checker runs with no login required, shows both WCAG 2 ratios and the APCA Lc score, renders a live preview in your chosen colors, and lets you test a full palette grid in one view. Every calculation runs locally in JavaScript — your colors never leave your device.

The WCAG contrast ratio formula: how the math actually works

The contrast ratio is computed 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 one. Relative luminance is not just a brightness average of RGB — it is a perceptually weighted, gamma-corrected value. Each sRGB channel is first divided by 255 to normalize it to [0, 1]. If the result is ≤ 0.03928 it is linearized as C_linear = C / 12.92; otherwise it is C_linear = ((C + 0.055) / 1.055)^2.4 — that exponent undoes the gamma encoding that sRGB applies when storing colors. The three linearized channels are then combined as L = 0.2126 × R_linear + 0.7152 × G_linear + 0.0722 × B_linear.

Those coefficients — 0.2126, 0.7152, and 0.0722 — reflect the human visual system's unequal sensitivity to red, green, and blue light. The eye is far more sensitive to green than to either red or blue, which is why a bright, saturated green can have much higher luminance than an equally bright red. This means a pure green on white (#00FF00) has a luminance of 0.7152 — almost as luminous as white itself — giving a contrast ratio of only about 1.37:1 even though it looks vivid.

The 0.05 offset in the formula serves two purposes: it prevents division by zero when both colors are pure black (L = 0), and it models the ambient reflectance of real display surfaces, which never achieve true zero luminance. Because both sides carry the same offset, the maximum possible ratio — pure white (L = 1) against pure black (L = 0) — works out to exactly 21:1, and two identical colors always give exactly 1:1. No other values are possible outside that range, which makes the ratio easy to interpret as a scale from no contrast to maximum contrast.

WCAG AA and AAA in practice: thresholds, definitions, and non-text contrast

WCAG 2 Success Criterion 1.4.3 (Contrast Minimum, Level AA) requires 4.5:1 for normal text and 3:1 for large text. WCAG defines large text precisely: at least 18pt (24px) at any weight, or at least 14pt (approximately 18.67px) when bold. Those are CSS pixel values at the default zoom level — the point sizes come from the print world and map to px at 96 dpi. Design tools like Figma often display font sizes in pts at arbitrary zoom; the value that matters for WCAG is the rendered CSS font-size in pixels at normal zoom on screen.

Level AAA (SC 1.4.6, Enhanced Contrast) raises the bar to 7:1 for normal text and 4.5:1 for large text. The WCAG specification itself acknowledges that AAA is not achievable across all content for all users, and it is not recommended as a blanket policy requirement for entire pages. AAA is best treated as a goal for reading-heavy contexts — long-form articles, medical or legal documents, anything where sustained low-vision reading matters.

WCAG 2.1 SC 1.4.11 (Non-Text Contrast, Level AA) extends the contrast requirement beyond text. The visual boundary of any interactive user interface component — the outline of an input field, a button's border, a checkbox's box, a toggle track — must achieve at least 3:1 against the adjacent background color. The same 3:1 requirement applies to meaningful graphical objects: icons that convey information, chart lines, map paths, and similar graphics. Decorative images and disabled components are exempt. This single criterion is behind a large share of modern accessibility audit failures because default browser and CSS-framework styles often ship with light-gray borders that barely reach 1.5:1.

Legal requirements, ADA lawsuits, and the European Accessibility Act

In the United States, the Americans with Disabilities Act (ADA) has been interpreted by courts to require accessible websites for covered entities. The DOJ's 2024 final rule under Title II formally codified WCAG 2.1 Level AA as the enforceable standard for state and local government websites — the first time a specific technical standard was written into ADA regulations. For federal agencies and their contractors, Section 508 of the Rehabilitation Act has required conformance to WCAG 2.0 AA since the 2018 refresh. Many federal procurements now also reference WCAG 2.1 or 2.2.

Private-sector website accessibility lawsuits under the ADA have grown sharply. US plaintiffs filed more than 4,000 digital accessibility lawsuits in 2023 — up from roughly 800 in 2017 — and contrast failures are among the most commonly cited violations in demand letters and complaints. The landmark case is Robles v. Domino's Pizza (9th Circuit, 2019): the court held that the ADA applies to the website and app of a business with physical locations, and the Supreme Court declined to hear Domino's appeal in 2020, letting that ruling stand across the 9th Circuit.

In Europe, the European Accessibility Act (EAA) entered enforcement as of June 28, 2025. It requires most digital products and services sold in the EU — e-commerce, banking, transport, media, e-books, telephony — to meet the EN 301 549 standard, which references WCAG 2.1 Level AA. Unlike the ADA, the EAA applies to private-sector companies regardless of whether they have physical locations. Non-EU companies selling digital products or services to EU consumers are also within scope, making WCAG 2.1 AA effectively a global commercial baseline for any product with European reach.

The APCA algorithm and the future of contrast in WCAG 3

The WCAG 2 contrast ratio has faced criticism for limitations that become apparent at the edges of real-world design. The formula treats a thin 12px font and a heavy 700-weight 16px font identically as long as both clear 4.5:1 — but bold text at 4.5:1 is demonstrably more legible than thin text at the same ratio. The formula also uses only two size categories (normal vs. large) with a hard cutoff, rather than modelling how legibility changes gradually with font size. These shortcomings are well-documented by vision scientists and motivated the development of a replacement algorithm.

The Advanced Perceptual Contrast Algorithm (APCA), developed by Andrew Somers, is the leading candidate for WCAG 3.0's contrast method. APCA returns an Lc (lightness contrast) value rather than a ratio. The scale runs roughly from −108 to +106; the sign encodes polarity — whether text is lighter or darker than the background — because the human eye perceives these differently. A dark-background layout with white text is not perceptually equivalent to a light-background layout at the same numeric ratio, and APCA models that asymmetry. Practical Lc targets from the APCA working guidelines: Lc 90 for preferred body text, Lc 75 as the body-text floor, Lc 60 for large display text, and Lc 45 for large decorative headings. APCA also provides a font lookup table that pairs minimum Lc values with specific font sizes and weights — a much finer-grained recommendation than WCAG 2's two-threshold system.

As of mid-2025, WCAG 3.0 remains a Working Draft and has no projected publication date as a W3C Recommendation. The W3C's Accessibility Guidelines Working Group has indicated the document is still undergoing significant structural revision, and APCA's integration is not yet final. Practically this means WCAG 2.2 Level AA — including the 4.5:1 and 3:1 thresholds — is still the current legal and technical standard everywhere. Running both scores side by side lets you verify today's legal requirements while positioning your palette for the likely direction of tomorrow's standard.

Practical design strategies for passing contrast every time

The most reliable strategy is to anchor your palette around a few known-safe values and build outward. #1a1a1a on white produces 18.1:1 — deep into AAA territory and indistinguishable from black to most eyes while avoiding pure black's harsh optical weight. For reversed text (light on color), any background darker than approximately #595959 will pass 4.5:1 with white text. The hex #767676 has become a benchmark in accessibility work because it is the lightest neutral gray that still passes 4.5:1 on a pure white (#FFFFFF) background — at exactly 4.54:1.

Placeholder text is one of the most commonly overlooked problem areas. Browsers default to a medium gray for placeholder copy inside inputs, and that default routinely fails WCAG 1.4.3. The WCAG specification confirms that placeholder text is not exempt — if it conveys a content hint to the user, it needs the same 4.5:1 contrast as regular body text. This is a frequent finding in formal accessibility audits of forms, search bars, and checkout flows.

Dark mode significantly increases the contrast verification burden. Every foreground-background pair that passes in light mode must be independently verified in dark mode — a palette that achieves 7:1 in light mode can easily produce ratios below 1.5:1 when colors are naively inverted. The common mistake is inverting a brand color without checking that it retains sufficient contrast against the dark background. A systematic approach is to define a dedicated dark-mode token set and run every combination through a pairwise grid check rather than checking individual pairs by hand, so that no combination is accidentally missed before shipping.