Color Contrast Checker

A colour contrast checker measures how far apart two colours are in perceived brightness and reports whether the result meets the thresholds set by the Web Content Accessibility Guidelines. You give it a foreground and a background; it gives you a ratio and tells you which requirements that ratio clears.

The reason it matters is that low contrast is one of the most common accessibility failures on the web, and one of the easiest to fix — usually a change to a single hex value. It affects people with low vision, people with colour vision deficiencies, and anyone reading on a dim screen or in bright sunlight, which over a long enough day is everyone.

It is also one of the few accessibility requirements that can be checked mechanically and answered with a number. That is its strength and its limit: a ratio settles a specific question completely, and tells you nothing at all about the dozens of other criteria a page has to meet.

A single number describing the distance between two colours in relative luminance, running from 1:1 for two identical colours to 21:1 for black on white. Those are the only two fixed points; everything else falls between them.

The formula is:

Relative luminance is not the same as the lightness value in a colour picker. Each sRGB channel is first gamma-corrected, then weighted — 0.2126 red, 0.7152 green, 0.0722 blue. Green carries almost three quarters of the perceived brightness and blue barely a fourteenth, which is why a saturated blue reads as much darker than a saturated yellow even when a picker shows both at 50% lightness.

Contrast is symmetric: swapping the foreground and background gives exactly the same ratio. That is worth knowing because it means the checker cannot tell which of your two colours is the text — and neither can the requirement.

Three success criteria govern contrast, and each sets its own bar.

A few exemptions are worth knowing. Text that is part of a logo has no contrast requirement. Nor does purely decorative text, or text in an image of significant incidental content such as a photograph. Inactive controls are exempt from 1.4.11. None of these is a loophole for body copy — they are narrow, and if you find yourself reaching for one, the honest answer is usually to fix the colour.

WCAG 2.2 did not change any of these numbers. It added criteria elsewhere and removed 4.1.1 Parsing; the contrast requirements are word for word what they were in 2.1. A palette that conformed under 2.1 conforms under 2.2, and any tool offering a 2.1-versus-2.2 switch that changes a threshold is inventing a difference.

1. Enter the two colours. HEX, RGB, HSL or a CSS colour name, or pick from the swatch. On Chromium browsers the eyedropper reads any pixel on screen, which is the fastest way to check a design you are looking at.
2. Read the ratio. It updates as you type. Each WCAG result names the threshold and the criterion it was judged against, so you can see not just whether it passed but what it was measured for.
3. Set the text size.The size tester decides whether the normal- or large-text thresholds apply, using WCAG’s point-based definition.
4. Fix what fails. The suggestions panel finds the nearest colour that reaches your target, keeping the hue and moving only lightness so it still belongs to your palette.

Measure against the colour that is actually behind the text. A card on a tinted page is measured against the card, not the page — a mistake that reliably produces a passing figure for a failing combination.

Large text gets a lower threshold — 3:1 for AA rather than 4.5:1 — because size does some of the work legibility otherwise needs contrast for. WCAG defines it as:

• At least 18pt at a regular weight
• Or at least 14pt bold

Note the unit. The definition is in points, not CSS pixels. The usual conversions are about 24px and 18.5px, and those are the figures most tools quote — but they are a consequence of the rule rather than the rule itself, and they stop matching the moment a page changes its root font size or a user zooms. WCAG also defines large scale differently again for Chinese, Japanese and Korean typefaces, where the same point size carries much more visual weight.

Treating “24px” as the rule is the common mistake. It is right often enough to feel safe and wrong exactly when a page is being resized, which is when accessibility matters most.

A link inside a paragraph has to clear two separate bars, and most tools only measure the first.

• Against the background. An ordinary text question: 4.5:1 for AA at body size, under 1.4.3.
• Against the surrounding body text. If colour is the only thing marking the link, a reader who cannot perceive that colour cannot find the link at all. That is 1.4.1 Use of Color.

The figure usually quoted for the second is 3:1 between link text and body text. It comes from WCAG technique G183 — a sufficient technique rather than a threshold written into the criterion — and G183 asks for something else as well: a non-colour cue on hover and on focus. Meeting the ratio alone does not establish conformance, which is why this tool reports it as guidance rather than as a verdict on 1.4.1.

The simpler answer is usually an underline. Underline the link and colour stops being the only distinction, the 3:1 separation stops being what carries the requirement, and you are free to pick the link colour on aesthetic grounds. Browsers underline links by default; removing it is a decision that costs something.

Whatever cue you choose, check it survives in forced-colours mode and Windows High Contrast, where author colours are replaced wholesale and a distinction that lived only in your palette disappears.

Same method, different thresholds. AA asks for 4.5:1 on normal text and 3:1 on large; AAA raises those to 7:1 and 4.5:1.

AA is the practical target. It is the level referenced by most accessibility legislation and procurement policy, and it is achievable across a whole site without flattening a design into black on white.

AAA is a goal, not a baseline. WCAG says so itself: conformance at AAA is not achievable for all content. It suits body copy on a text-heavy page, and it constrains a palette hard — at 7:1 against white, a great many brand colours have no usable version at all.

A reasonable position: hold body text to AAA where you can, hold everything to AA, and treat a failure at AA as a bug rather than a preference.

• Move lightness, not hue. Darkening the text or lightening the background keeps the colour recognisably yours. Changing the hue produces a passing ratio and a different design.
• Change the background instead. Often the honest fix. Muted text on a tinted card frequently passes the moment the card goes white.
• Make the text larger or bolder. Crossing into large text drops the AA requirement from 4.5:1 to 3:1, which is a substantial change.
• Stop using the brand colour for body text. Brand colours are chosen for recognition at large sizes. Most have no version that passes at 11pt on white, and using them for prose is the single most common source of failures.
• Remove the overlay, or make it solid. Text over an image or a gradient has no single ratio. A solid backdrop behind the text is the fix.
• Do not fix it with opacity. Reducing opacity to soften text lowers the ratio, which is the opposite of what was wanted. Pick a lighter colour outright so the value is visible in the code.

A palette is not a set of colours. It is the set of combinations somebody will build from those colours, and the failures live in the combinations. Five swatches that each look fine produce ten pairs, and it only takes one bad pair to put unreadable text in a component.

That is what the palette matrix above is for. Rather than checking pairs as you happen to think of them, it checks all of them and shows you the weakest.

Practical habits that avoid most problems:

• Design the text colours against the surfaces they will actually sit on, not against white in isolation.
• Keep a deliberately dark shade and a deliberately light shade of each hue, so there is always a passing option to reach for.
• Check muted and secondary text hardest. It is the first thing lightened for visual hierarchy and the first thing to fail.
• Check both themes. A pair that passes on white can fail badly on a dark background, and the WCAG 2.x formula is known to be unkind to dark surfaces.

For building and converting individual colours, the colour picker handles HEX, RGB, HSL and OKLCH.

Success criterion 1.4.11 Non-text Contrast requires 3:1 for the parts of interface components and graphics you need to see in order to use or understand them. It is newer than the text criteria and much more often missed.

What it covers:

• The boundary of a form control — the border that tells you where the field is.
• The state of a control: which radio is selected, which way a toggle is set.
• Focus indicators. The most common failure of the lot. A default outline removed and replaced with a faint one fails, and it fails for exactly the people who depend on it.
• The meaningful parts of an icon or chart — the strokes that carry the information, not every pixel.

What it does not cover:

• Purely decorative graphics.
• Inactive or disabled controls.
• Detail internal to a graphic that carries no information of its own — a shadow, a gradient, a texture.
• Logos and brand marks as they are.

A useful check: turn off every colour in a component and ask whether you could still tell what state it is in. If not, colour is doing work it should not be doing alone.

Contrast is cheapest to fix in the palette and most expensive to fix in a component library that already ships. The earlier the check, the smaller the change.

For designers. Check the pairs when you define the palette, not when a page is built from it. Note the ratio next to each token. Where a brand colour has no passing version at body size, decide then what it is for — and it is usually large headings, buttons with a dark fill, or accents rather than prose.

For developers. The colours that fail are rarely the ones in the design file; they are the ones that emerge from a hover state, a disabled variant, a placeholder, or a component reused on a surface it was not designed for. Check the states, not just the default. Anything computed from a token at runtime — an opacity, a mix, a filter — needs checking as the browser will actually render it.

For both. Automated checks belong in the workflow but they close a narrow question. Testing with a real screen reader, at 200% zoom, and in forced-colours mode finds the problems a ratio never will.

A contrast checker answers one question precisely. Being clear about what it does not answer is what keeps the number useful.

• It is not a conformance test. Contrast is a handful of criteria out of dozens. Passing every ratio on a page says nothing about headings, labels, keyboard access, focus order or alternative text.
• It cannot settle 1.4.1 Use of Color. That depends on hover and focus states, and on whether information is conveyed by colour anywhere else on the page. No colour comparison observes any of that.
• Gradients, images and video have no single ratio. The background differs at every point. Measure the worst case, or put a solid backdrop behind the text.
• Transparency has to be composited first. A translucent colour has no ratio of its own — it depends entirely on what is behind it. This tool composites and then flags the result for manual review.
• The formula itself has known limits. WCAG 2.x contrast is recognised to be unkind to dark backgrounds and to overstate some mid greys. APCA is the intended successor and is not yet normative, so conformance is still judged on the 2.x maths — which is what this tool implements.
• Simulation is not evidence. A colour-vision filter helps you see a problem. It does not prove conformance, and no simulated ratio has any standing.

Automated contrast checks identify many common issues, and they do not replace a complete accessibility audit or manual WCAG testing. A failure here is a defect worth fixing; it is not a legal finding, and this tool issues no compliance certification.