Check Color Palette for Color Blindness

How the palette checker works

You build a palette here — type or paste hex codes, pull from the presets, or drop in a whole list at once — and the tool renders each color twice: once as you see it, and once as it appears under the type of color vision deficiency (CVD) you pick. The simulated swatch is produced by converting each hex value to linear RGB, running it through a cone-response matrix for that CVD type, and converting back. The point is comparison. Two colors that look clearly different to you can land almost on top of each other for a color-blind viewer, and putting the original and simulated swatches next to each other is the fastest way to catch it.

Alongside the swatches, the checker calculates the WCAG contrast ratio between adjacent colors so you can see, as a number, whether a pair has enough luminance separation to stay readable. A pair can pass a contrast check and still be a bad idea for encoding meaning — contrast and hue-discriminability are different problems — so read both signals together rather than trusting either one alone.

Everything runs locally in your browser. Nothing about your palette is uploaded, stored, or logged, so it is fine to test unreleased brand work or client colors. When you are done you can export the set as PNG, JSON, or CSS custom properties.

The one rule that matters most: don't separate meaning by hue alone

Red-green color deficiency is by far the most common form — deuteranomaly (weak green) is the single most common type, and red-green types together affect roughly 1 in 12 men and 1 in 200 women. For those viewers, hues that sit on opposite sides of the red-green axis can collapse toward the same muddy tone. What almost always survives is lightness. Even when hue information is gone, most people with CVD still read light-versus-dark clearly.

So the practical rule is to build separation into luminance, not just hue. If your categories differ only in color wheel position — say, a red and a green of the same lightness — they can become indistinguishable. Give them different lightness values and the difference holds up even in a fully grayscale view. That single habit fixes the majority of palette accessibility problems before you ever add a second cue. For a step-by-step walkthrough, see our guide on how to choose accessible color palettes.

Color pairs to be careful with

A few pairings are risky specifically because they converge under common red-green deficiency. If any of these carry meaning in your design — status, categories, on/off — simulate them first and vary lightness or add a non-color cue:

• Red / green — the classic. The two sit near opposite ends of the axis that red-green viewers can't resolve, so they can read as the same brownish tone.
• Green / brown — brown is essentially a dark orange-red, and it drifts toward green when the red signal is weakened.
• Green / black — a mid or dark green can lose its greenness and read as just another dark neutral.
• Blue / purple — purple is blue plus red; drop the red contribution and it slides toward plain blue.
• Light green / yellow — both are bright and low in the red-green signal, so they flatten into a single pale tone.
• Blue / gray — a desaturated blue can be hard to separate from a neutral gray, especially at similar lightness.

None of these are banned. They fail when they're the onlything telling two items apart. Blue and purple can coexist happily in a palette as long as you never ask a viewer to tell “blue means X, purple means Y” by color alone.

What the WCAG standards actually require

Three success criteria in the Web Content Accessibility Guidelines are the ones that touch color directly. WCAG 2.1 Level AA is the target most teams (and most accessibility laws) aim for.

• 1.4.1 Use of Color (Level A) — color must not be the only visual means of conveying information, indicating an action, or distinguishing a visual element. This is the criterion your palette choices most often bump into: a red-means-error / green-means-ok scheme with no icon or text label fails it, regardless of how nice the colors are.
• 1.4.3 Contrast (Minimum) (Level AA) — text needs a contrast ratio of at least 4.5:1 against its background, or 3:1 for large text (roughly 18pt, or 14pt bold, and larger).
• 1.4.11 Non-text Contrast (Level AA) — user interface components and meaningful graphical objects — icons, input borders, chart segments, the slices of a pie — need at least 3:1 against what's next to them.

The contrast readouts in this tool use the same relative-luminance formula the WCAG thresholds are built on. One honest caveat: an automated ratio can't judge intent. It won't tell you whether two adjacent chart colors mean different things, and it can be over-strict about large decorative text. Use the numbers as a strong signal, not a verdict.

Palettes for charts and data visualization

Categorical charts are where color-only design fails hardest, because the color isthe data. A few things keep them readable:

• Start from a palette that was designed to stay distinct under CVD. The Okabe-Ito set (eight colors) and ColorBrewer's color-blind-safe schemes are both built for exactly this and save you a lot of guessing.
• Limit how many categories share one chart. Even a good palette runs out of safely distinguishable colors somewhere around six to eight series; past that, split the chart or group the tail.
• Label data directly on the marks — a line labeled at its end, a bar with its value on it — instead of routing every reader through a color legend.
• Add a redundant channel: patterns or textures for fills, distinct marker shapes for scatter points, dashed vs. solid for lines. These survive when hue doesn't.

A legend that maps six near-identical grays to six labels is technically present and practically useless. If a viewer has to hop back and forth between the legend and the marks to keep them straight, the encoding is doing too much work.

Fixing a palette that fails

When the simulated view shows two swatches merging, you have three levers, roughly in order of how little they disturb your design:

• Adjust lightness. Push one color lighter or darker so the pair separates on luminance. Often you can keep both hues and just spread them apart in tone. The per-swatch suggestions here nudge in this direction.
• Add a second cue. Back the color with a text label, an icon, or a texture, so the meaning no longer depends on anyone perceiving the hue. This is also what satisfies SC 1.4.1.
• Swap one of the converging pair. If two colors sit on the same collapsing axis — a red and a green, a blue and a purple — replace one with a hue from a different part of the wheel, then re-check.

Re-run the simulation after each change, and test the red-green types first (deuteranopia and protanopia) since they cover the most people. If a palette holds up there and in the grayscale view, it will hold up for nearly everyone.

Example: Palette Color Blindness Simulation

Frequently asked questions

Related reading

Try Another Tool