Colour Contrast Checker

How to use it

1. Enter two colours. Hex, rgb(), hsl() or a colour name all work, and there is a picker beside each field.
2. Read the five results. A pairing usually has to satisfy more than one requirement, so all of them are shown at once rather than just the headline number.
3. Take the suggestion if it fails. The tool gives you the nearest colour that passes, with the hue left where it was.

Switch to palette mode to check every pairing in a set of colours in one pass.

What a contrast ratio actually is

It’s a single number between 1 and 21 describing how far apart two colours are in luminance — how much light they emit — rather than in hue.

The calculation converts each colour to relative luminance, weighting the channels 0.2126 red, 0.7152 green and 0.0722 blue. Those weights are not arbitrary: human eyes are far more sensitive to green light than to blue, so green contributes about ten times more to perceived brightness than blue does.

Then it divides the lighter luminance by the darker, offsetting both by 0.05:

ratio = (L_lighter + 0.05) / (L_darker + 0.05)

Black on white gives exactly 21:1. Any colour against itself gives 1:1. The order of the two colours doesn’t matter — the ratio is the same either way.

The consequence worth internalising: two colours can be wildly different and still fail. Pure red on pure blue is visually jarring and scores 2.15:1, which is not enough for any text at any size.

What WCAG requires

AA is the level that matters in practice. It’s what the EAA, the ADA in effect, Section 508 and EN 301 549 all land on. AAA is a stretch goal that WCAG itself says is not achievable for all content — you don’t need it, and chasing it usually costs you a design you liked for no legal benefit.

The definition of “large” catches people out. It’s 18 point, which is 24 pixels — not 18 pixels. A 20px heading is still normal text as far as WCAG is concerned and needs the full 4.5:1.

Checking a whole palette

Most contrast tools check one pair. That’s fine when you have one question and a nuisance when you have a brand palette, because the number of pairings grows fast:

Paste the whole set and every pairing is scored at once, sorted best first, so the failures collect at the bottom where you can see them together. It’s capped at 20 colours — 190 rows is already a long table, and 50 colours would produce 1,225.

What this is really for is finding out which of your brand colours can legally carry text and which can only ever be decoration. That’s a question about the palette as a whole, and it’s tedious to answer one pair at a time.

Non-text contrast, the requirement everyone forgets

SC 1.4.11 arrived in WCAG 2.1 and most contrast tools still ignore it. It requires 3:1 for things that aren’t text but still carry meaning:

• The boundary of a form input. A 1px #e5e5e5 border on white is 1.26:1 — invisible to a lot of people, and a very common failure.
• Focus indicators. If your focus ring doesn’t clear 3:1 against both the component and the page behind it, keyboard users can’t see where they are.
• Icons and graphics that convey information. A warning triangle has to be distinguishable. A purely decorative flourish doesn’t.
• Chart segments, toggle states, required-field markers.

The pale-grey-border-on-white input is the single most common non-text failure on the web, and it is almost always an aesthetic decision nobody revisited.

Colour blindness and contrast

The simulation shows your pairing as it appears with each of the three types of dichromacy. The instructive part is that the contrast ratios barely move.

That the ratios hold steady is the point: contrast and hue discrimination are different problems, and passing one tells you nothing about the other.

Take dark red #8b0000 on light green #90ee90. That scores 7.06:1 — comfortably past AA, past AAA. Run it through the deuteranopia simulation and it becomes a dark brown on tan at 9.47:1. Still readable. The text was never the problem.

What vanished is the redness. If red versus green was carrying the meaning — error versus success, over budget versus under — that information is simply gone, while the contrast score sat there looking healthy the whole time.

Which is why SC 1.4.1 exists separately: never use colour alone to convey information. A red “invalid” field needs a message as well as a red border. A green “success” tick needs the word. Contrast passing tells you nothing about whether you’ve done that.

APCA and WCAG 3

The WCAG 2 formula has a known weakness: it treats dark-on-light and light-on-dark symmetrically when human vision doesn’t. White text on a mid-grey background often measures the same as the reverse and reads noticeably worse.

APCA — Advanced Perceptual Contrast Algorithm — is the replacement drafted for WCAG 3. It produces a lightness contrast value Lc from about −108 to 106, where the sign tells you the polarity: positive is dark text on light, negative is light on dark.

It is not normative and this tool never scores it as a pass or a fail. WCAG 3 is years from being a recommendation, conformance today is judged entirely on the WCAG 2 ratio, and any tool telling you that you “pass APCA” is inventing a threshold that does not exist yet. It’s shown here because it’s genuinely informative when the WCAG 2 number feels wrong.

Why dark mode fails when light mode passed

A pattern worth knowing about, because it catches teams who did the contrast work properly the first time.

You pick a brand blue that passes on white. Then you build a dark theme and reuse the same blue on a near-black background. It measures fine. It looks wrong — thin, buzzing, harder to read than the number suggests.

Two things are happening. The WCAG 2 formula treats both polarities identically, but human vision doesn’t: light text on dark backgrounds appears to bloom slightly, which makes fine detail harder to resolve. And saturated colours that sit comfortably on white tend to be too dark against black.

The practical fix is not a formula, it’s a habit: dark mode needs its own colour values, not the same ones inverted. Most mature design systems lighten and desaturate their accent colours for dark themes for exactly this reason. Check both themes as separate pairings — the palette mode is useful here, because you can paste both sets and see them scored together.

Checking a whole website

This tool takes colour values, not URLs, and that’s a deliberate limit rather than an oversight. A page can’t read the rendered styles of another site — browsers block cross-origin access, and any web page claiming to scan your site for contrast is either running a server-side crawler or is a browser extension with different permissions.

For a whole site, the practical sequence is:

1. Start with the design tokens, not the pages. Most sites have ten to thirty colours in total. Paste them here in palette mode and you’ve covered nearly everything in one pass.
2. Use a browser extension or DevTools for the exceptions — the places where a colour got hard-coded outside the system.
3. Check the states, not just the resting styles. Hover, focus, disabled, error and visited all have their own colours and are routinely missed.
4. Check both themes. See above.

Disabled controls are the usual argument. WCAG exempts inactive components from the contrast requirements, so a greyed-out button technically passes by being exempt. That is a legal position, not a usability one — if users can’t read what the disabled button says, they can’t tell what’s unavailable.

Worked example

A common one. You have #767676 grey text on white and you want to know if it’s safe.

#767676 is the lightest grey that passes AA on white, which is why it turns up in so many design systems. Nudge it one step lighter to #777777 and the ratio drops to 4.48:1 — a failure, from a change nobody would notice by eye.

That margin of 0.04 is worth respecting. If your brand grey sits at 4.5 exactly, any future tweak to the background breaks it.

What this tool will not tell you

Contrast is one success criterion out of roughly fifty at WCAG 2.2 AA. Passing it is necessary and nowhere near sufficient.

Automated checking of every kind — this tool, browser extensions, the expensive enterprise scanners — catches only about 30 to 40 per cent of real accessibility barriers. The rest need a person. Keyboard traps, illogical focus order, form fields whose labels are visually adjacent but not programmatically associated, images with alt text that describes the wrong thing, a modal that doesn’t return focus when it closes: none of that is detectable by machine.

So this page reports ratios and thresholds. It does not tell you a page is accessible, it does not issue a certificate, and you should be suspicious of anything that offers to.

Related tools

Once your colours are settled, the accessibility statement generator produces the published statement the European Accessibility Act requires, including the honest list of known limitations. Colour values are just bytes underneath, and the hex, binary and ASCII converter turns a hex triplet into its decimal RGB components. For the content itself, the invisible character detector finds zero-width characters that break screen-reader output, and the case converter helps with all-caps headings, which are measurably slower to read and a genuine accessibility problem in their own right.