👁 Color Blindness Simulator

By Λ · Updated May 18, 2026 · ~3 min read

Why this matters

Roughly 8% of men and 0.5% of women have some form of color vision deficiency. In a UI used by hundreds or thousands of people, the assumption that everyone can distinguish red from green is wrong for about 1 in 12 of your users. Charts that rely on color-coding to convey meaning, status indicators that go "green = good, red = bad", and forms with red-only validation states all fall apart for these users.

I built this simulator after one of my own dashboards completely failed a color-vision user-test with a friend who happens to have deuteranopia. The dashboard's "red = error, green = success" status badges were both the same muddy yellow-brown to him. This tool exists so I can catch that kind of problem before the user does.

How the simulation works

The math is from Brettel, Vienot, and Mollon (1997), which is still the standard model used by Coblis, Color Oracle, and the Chrome accessibility tools. The image's RGB pixels are converted to LMS color space (Long, Medium, Short wavelength cones), a matrix transformation simulates the missing or shifted cone, and the result is converted back to RGB. The whole pixel pass runs through Canvas's getImageData right here on the page, so the picture you drop in is transformed on your own machine rather than being uploaded anywhere.

What to test

• Status badges and chips. If "success" and "error" look identical in any simulation column, add an icon or text label.
• Charts that use color as the only encoding. Color-coding plus shape or pattern is the accessible pattern.
• Form validation states. Red borders are not enough; use an icon plus text.
• Heatmaps and gradients. Viridis and Cividis palettes were designed to be perceptually uniform across color vision deficiencies. Use them.
• Required-field markers. A red asterisk is invisible to ~3% of users. Use the word "required" too.

Limitations of any simulator

This is a model, not the actual experience. People with color vision deficiency adapt over their lifetime; they have learned to use contextual cues, brightness, and color positioning that a static simulation cannot replicate. The simulator is a quick-check tool for designers, not a substitute for user research with people who actually have the condition.

Related

For WCAG contrast checking on text and UI, see the contrast checker. For palette generation that takes accessibility into account, see the color palette tool. There's also a full blog post on color accessibility for developers.

Frequently asked questions

Which deficiency types does the simulator show?

Five panels render side by side after you load an image: the untouched original plus protanopia, deuteranopia, tritanopia, and achromatopsia. The first three apply cone-transform matrices, while the achromatopsia panel is computed from plain luminance weighting, which is why it appears as pure grayscale.

Can I paste a screenshot instead of uploading a file?

Yes. The page watches for clipboard paste events, so you can screenshot a UI, switch to this tab, and press Ctrl+V without saving a file first. Dragging an image onto the drop zone gets you the same result.

Why do large images come out smaller than the original?

Anything wider than 800 pixels is scaled down before the per-pixel pass so all five canvases render quickly. The previews are meant for visual checking, not as full-resolution exports.

Does it cover milder conditions like deuteranomaly?

No. The matrices model complete dichromacy, where one cone class is missing outright. Anomalous trichromacy is a weaker shift of the same cone, so read each panel as the worst-case version of that deficiency.