WCAG 2.1 AA Contrast Ratio Checker for Dark Mode Design

Drop pure black (#000000) and switch to #121212 for your primary background

Pure black creates severe eye strain because your pupils constantly adjust to extreme edge contrasts, while #121212 preserves depth without triggering discomfort. This single substitution immediately improves readability and aligns with modern dark mode interface design standards. When you pair #121212 with #E0E0E0 text you get a 14.19:1 contrast ratio, which clears the WCAG 2.1 AA threshold of 4.5:1 for normal text and the AAA threshold of 7:1 as well. Start here before touching any other element, and check the rest of the palette against the same two panels.

Calculate relative luminance before selecting secondary colors

Visual brightness lies to designers. What appears as a soft gray on your calibrated display might actually fail accessibility tests due to how human photoreceptors perceive different wavelengths. Relative luminance measures the absolute brightness of a color, independent of screen gamma or ambient lighting. You derive it by applying the sRGB linearization formula to each RGB channel, then weighting red at 0.2126, green at 0.7152, and blue at 0.0722. For instance, the hex code #3A3B3F yields a relative luminance of 0.043864 — noticeably darker than the 0.062 that is often quoted for it. Plugging that alongside your background into the contrast equation reveals whether your chosen hue will survive real-world conditions. Never guess when working with color conversion tools; let the math dictate your palette boundaries and prevent late-stage rework.

Apply the standard contrast formula correctly

The standard is a straightforward division: (L_lighter + 0.05) ÷ (L_darker + 0.05). Using the verified values, #E0E0E0 (luminance 0.745404) against #121212 (luminance 0.006049) gives (0.745404 + 0.05) ÷ (0.006049 + 0.05) = 14.19:1. That comfortably clears every WCAG 2.1 threshold for normal text, including AAA at 7:1. When you run smaller UI elements or icons, the required threshold drops to 3:1, but maintaining the higher benchmark future-proofs your design against aging displays and compromised viewing environments.

Run every foreground and background pair through a wcag 2.1 aa contrast ratio checker

Manual inspection introduces unavoidable bias. Your brain compensates for poor contrast by mentally reconstructing missing information, meaning what feels crisp on a high-end monitor might dissolve on budget hardware or under bright overhead lighting. A dedicated wcag 2.1 aa contrast ratio checker strips away subjective perception and processes raw values against the standardized algorithm. Work through your component library one color at a time rather than only checking isolated headers. Note what a single-field checker can and cannot do: it evaluates one color against white and against black, so the tokens file, the batch run and the threshold report all belong in your own build pipeline. What you get here is the luminance of each value, from which any pair is one division away. Treat these results as non-negotiable constraints. Catching violations during the prototyping phase removes a whole class of late rework and the user complaints about unreadable menus that come with it.

Integrate validation into your daily workflow

Automation consistently outperforms manual spot-checking. Attach your contrast verification step directly to your design system or version control pipeline. Modern editor plugins can overlay ratio metrics straight onto your artboard, highlighting failures in real time. For custom development environments, script a lightweight utility that parses your CSS variables and generates a compliance summary. When validation becomes an invisible gatekeeper, teams stop bypassing accessibility checks to meet arbitrary deadlines. Consistency scales naturally when the barrier to entry is lowered and the path to compliance is automated.

Validate hover, focus, and disabled states independently

Static compositions rarely reflect actual user interaction. Interactive elements require distinct visual cues to communicate affordance, and those transitions frequently slip below minimum thresholds. A navigation link that reads cleanly at rest might lose its underline and darken by only eight percent on hover, instantly breaching the 3:1 requirement for graphical objects and interface components. Always test state variations separately. Implement focus rings that satisfy the 3:1 rule against both the target element and its immediate background. Disabled controls should retain structural clarity rather than fading into obscurity. Mapping these micro-interactions prevents cognitive friction and keeps your dark mode interface design compliant across every touchpoint.

Preserve hierarchy without shifting base shades

When a color pairing approaches the compliance edge, resist the temptation to lighten the text or darken the container. Instead, leverage typographic scale. Increasing font weight from regular to medium or bold dramatically boosts perceived contrast without altering the underlying luminance values. Pair this adjustment with measured letter spacing to enhance character differentiation. Typography and color operate as a unified system; tweaking one often conceals flaws in the other. By stabilizing hue and manipulating weight, you maintain brand integrity while satisfying rigorous accessibility benchmarks.

Log your contrast data inside a centralized design token system

Scattered spreadsheets inevitably lead to fragmented implementations. Every resilient dark mode interface design depends on a single source of truth where color values, their computed luminance, and corresponding contrast ratios coexist. Build a token registry that pairs each semantic variable with its verified metrics. When engineers consume these tokens, they inherit pre-approved combinations that already cleared your wcag 2.1 aa contrast ratio checker. Future iterations become simple parameter swaps rather than blind experiments. Documenting your palette transforms accessibility from a reactive checklist into a proactive architectural foundation.

Audit regularly as hardware and OS features evolve

Display technology shifts continuously. New OLED matrices, adaptive brightness curves, and system-wide night modes fundamentally change how audiences experience digital content. Schedule quarterly reviews of your color documentation. Run fresh scans across representative devices and operating system themes. Minor calibration drifts from manufacturers can push previously safe combinations toward the failure boundary. Proactive maintenance guarantees that your interface remains durable and that compliance survives long after the initial launch window closes.

What the Checker on This Page Actually Tests

Paste a color into the single field and the page treats it as a foreground. It accepts a hex code (3, 4 or 6 digits), an `rgb()` or `hsl()` function, a `cmyk()` function, or a CSS color name, and a badge reports which of those it recognized. Below the swatch, two panels render the same color as text on a fixed surface: one on white and one on black. Each panel shows a live sample line, the contrast ratio to two decimal places, and four pass/fail badges.

Those badges come from the WCAG 2.1 definition, computed in the page and not looked up from a table. Each sRGB channel is divided by 255, and if the result is 0.03928 or below it is divided by 12.92; otherwise it goes through `((v + 0.055) / 1.055) ^ 2.4`. The three linearized channels are then weighted 0.2126 red, 0.7152 green and 0.0722 blue to give relative luminance, and the ratio is `(L_lighter + 0.05) / (L_darker + 0.05)`. The four verdicts are 4.5:1 for normal AA text, 3:1 for large AA text, 7:1 for normal AAA text and 4.5:1 for large AAA text.

There is a second meter underneath that is often mistaken for the same thing. The brightness bar uses the ITU-R BT.601 weighting — 0.299 red, 0.587 green, 0.114 blue — scaled to a percentage. It tells you whether a color reads as light or dark. It is not a compliance score, and a color can sit at 50% brightness while failing both contrast panels.

Checking Any Pair, Even With Only One Input

The panel gives you two ratios for the same color, and both are invertible. Against black, the ratio reduces to `(L + 0.05) / 0.05`, so the luminance is `L = 0.05 × (R_black − 1)`. Against white it reduces to `1.05 / (L + 0.05)`, so `L = 1.05 / R_white − 0.05`. Run both and they should agree — which makes the two panels a built-in arithmetic check on each other.

Take `#121212`: the black panel reports about 1.12:1, giving `L = 0.05 × 0.12 = 0.006049`, and the white panel reports about 18.73:1, giving `L = 1.05 / 18.73 − 0.05 = 0.006049`. Same answer. Once you have the luminance of each color, any pair you care about is one division away, and the need for a second input field disappears.

The Dark-Mode Numbers, Re-Derived

Working the formula through by hand for the values this topic always comes with produces numbers that are worth having straight:

• #121212 has a relative luminance of 0.006049, not the 0.004 that circulates in dark-mode write-ups. That is derived above from the panel's own two ratios.
• #E0E0E0 has a relative luminance of 0.745404 — commonly quoted as 0.783, which would be a noticeably lighter gray.
• The pair therefore yields 14.19:1: (0.745404 + 0.05) / (0.006049 + 0.05). It clears 4.5:1 and 7:1 for normal text, so it passes AA and AAA without any adjustment. Ratios of 13.6:1 and 15.4:1 both appear in circulation for this exact pairing; neither survives the arithmetic.
• #000000 against #E0E0E0 is 15.91:1. Pure black therefore buys about 1.7 points over #121212 at the same text color — real, but not the difference between passing and failing. The argument against pure black is about comfort and halation on OLED panels, not about the standard.
• #1E1E1E against #E0E0E0 is 12.63:1, still comfortably AAA for normal text, which is why a slightly lifted near-black is the usual compromise.
• #3A3B3F has a luminance of 0.043864, not the 0.062 sometimes suggested. On white that is 11.19:1; on #121212 it collapses to 1.67:1 and fails every threshold. #3A3B3F is a surface, not type.
• #BB86FC, a familiar dark-theme accent, sits at 7.07:1 against #121212, which is enough for normal AAA text.

States, Icons and the 3:1 Floor

The 3:1 badge in each panel is doing double duty. It is the large-text AA threshold and also the floor WCAG 1.4.11 sets for user interface components and graphical objects. That is why a focus ring, a checkbox border or an icon that carries meaning is judged against 3:1 rather than 4.5:1.

Because the checker evaluates one color at a time, state variants are checked one value at a time. Paste the hover color, note its luminance against the surface, then paste the focus color and do the same. Disabled controls are explicitly exempt from the contrast requirements, but a disabled state that is indistinguishable from an enabled one is a usability problem regardless of what any ratio says.

One adjustment will not move the badges. Raising font weight from regular to semibold, or adding letter spacing, improves how legible the text feels, but the computed ratio depends only on the two colors' luminance. If a pair fails at 4.2:1, weight will not turn it into 4.5:1. Change the color, or lower the surface's luminance, or promote the text to a size that qualifies as large.

Using It Without Overclaiming

The contract of this tool is narrow and worth stating plainly: it answers "how does this color read on white, and how does it read on black". It does not import a token file, it does not batch-test a component library, it does not parse your CSS variables, and it exports nothing. Anything automated along those lines has to live in your own build pipeline or design tooling, and the ratios it would compute are the same ones shown here.

For a dark theme, the fast routine is three passes. Paste the background, read its luminance off the panels. Paste the body text color, read its luminance the same way. Divide the two, then repeat for the muted text, the link color and the icon color. That is a handful of divisions, and it is the whole of the accessibility question for a dark palette — everything else in this article is about deciding which values to feed in.