3 Color Blindness Simulators, Compared Honestly

The status indicators in your interface are red for failing and green for passing, and someone has just pointed out that a meaningful share of your users cannot reliably tell those two apart. Before you redesign anything, you want to see what the pair actually looks like to them — and know whether the contrast between them holds up.

These are two separate checks that people routinely collapse into one. Simulating a colour vision deficiency tells you whether the hues remain distinguishable. A WCAG contrast ratio tells you whether the luminance difference is enough for someone with low vision. A red and a green of identical lightness can pass neither, or pass one and fail the other, and only running both tells you which problem you have.

How to judge a colour vision simulator

Does it cover the main conditions separately? Deuteranopia, protanopia, and tritanopia affect different cones and produce different results. One generic “colour blind” filter is not enough.

Does it report contrast as well? Simulation and contrast answer different questions, and you need both before you sign off a palette.

Does it work on colour pairs or on images? Checking two hex values is a design decision. Checking a screenshot is a review.

Is the model principled? Simulations are approximations of perception, and how they are derived varies between tools.

The comparison

Facts checked August 2026; plans can change.

DevPalettes

DevPalettes is the closest of the three to a designer’s working loop. It simulates protanopia, deuteranopia, tritanopia, and achromatopsia, and pairs that with a built-in WCAG contrast checker, stating no sign-up and no downloads — enter your colours and see both results immediately.

It is built around colour inputs rather than artefacts. For evaluating a palette that is exactly right; if what you have is a screenshot of a dashboard, you are reaching for something else.

DeficiencyView

DeficiencyView is the most flexible about what you feed it: upload an image or test a live URL, simulating deuteranopia, protanopia, tritanopia, and achromatopsia, with a WCAG contrast checker included. Testing a real page is the most honest form of this check, because it catches the colour decisions you forgot you had made.

Testing a URL means the service loads that page, which is worth noting for anything behind authentication or not yet public. For those, upload a screenshot instead.

CoBlind

CoBlind does one thing quickly: upload an image and simulate protanopia, deuteranopia, tritanopia, and other deficiencies in seconds, stated as 100% free. For showing a stakeholder why the red-green indicator is a problem, an image they recognise is the most persuasive artefact you can produce.

It is image-focused, so there is no contrast ratio for a specific foreground and background pair. It answers the hue question and leaves the luminance one open.

Color Contrast Simulator by Condition

Ours takes a foreground and background colour pair and shows how it appears under deuteranopia, protanopia, or tritanopia, with the resulting contrast ratio against WCAG thresholds shown alongside. Both checks, one screen, on the specific pair you are deciding about. It runs entirely in your browser.

The limitations are worth being direct about. Simulation is a model of perception, not an experience of it — colour vision deficiency varies in type and severity, and no filter reproduces what an individual actually sees. It also works on a colour pair rather than a page, so it will not catch a problem elsewhere in your interface, and it cannot tell you whether colour is carrying meaning that should have had a label or an icon beside it. The most important accessibility fix in this area is usually not a better colour, it is not relying on colour alone.

Which one to pick

• If you are choosing UI colours and want simulation plus contrast on the values themselves, use DevPalettes.
• If you want to review a whole page or a screenshot, DeficiencyView handles both.
• If you need a persuasive image to show someone, CoBlind produces one fastest.
• If you are deciding on one foreground and background pair, use ours.

How to do it with Color Contrast Simulator by Condition

1. Open the Color Contrast Simulator by Condition.
2. Enter the foreground and background colours you are considering.
3. Step through deuteranopia, protanopia, and tritanopia and check the pair stays distinguishable.
4. Read the contrast ratio against the WCAG threshold for your text size. More accessibility tools are in the tools directory.

You might also need

• Contrast Ratio Checker — for checking a set of pairs against the thresholds quickly.
• Accessible Palette Suggester — when the pair fails and you need alternatives.

Frequently asked questions

Is there a free colour blindness simulator that doesn’t need an account?

Yes — DevPalettes states no sign-up, CoBlind and DeficiencyView are free tools, and ours requires no account because the site has no signup at all.

What contrast ratio do I need?

For normal-size text, WCAG 2.2 sets a minimum of 4.5:1 at level AA, dropping to 3:1 for large text, with higher thresholds at AAA. The W3C’s understanding document for contrast sets out the sizes and exceptions.

Is passing contrast enough for accessibility?

No. Contrast covers luminance, and it says nothing about whether colour alone is carrying information. If red versus green is the only signal distinguishing pass from fail, adding an icon or a label fixes the problem for far more people than adjusting the hues will.

Final thought

Run the simulation and the contrast check together, then ask whether the colour needed to carry the meaning at all. The colours are worth getting right; not depending on them is worth more.

Try the free Color Contrast Simulator by Condition