Color-Blindness Simulator

How it works

Each dichromacy type results from one of the eye's three cone types (long/red, medium/green, or short/blue) being non-functional; the simulator applies the Machado, Oliveira, and Fernandes (2009) linear transformation matrices, published research that models how a trichromatic sRGB color would appear if one cone response were entirely absent, derived from actual physiological cone-response data rather than a simple hue-shift approximation. The RGB values pass through the matrix in linear-light space (after gamma decoding), then convert back to gamma-corrected sRGB for display — skipping the linear-light step is a common simulator bug that produces visibly wrong results, which color-core avoids. The three dichromacy types don't affect color perception uniformly: protanopia additionally dims perceived brightness in the red end of the spectrum (since the missing L-cone also contributes to luminance perception, not just hue discrimination), which is a subtlety a pure hue-shift simulation would miss entirely but the Machado matrices, derived from real measured cone sensitivities, capture correctly.

Worked example

A saturated red-green pair like #E53935 (red) next to #43A047 (green) — a genuinely common 'error vs. success' UI pairing — simulated under deuteranopia (red-green colorblindness, the most common type) collapse toward very similar muddy yellow-brown tones, nearly indistinguishable from each other, which is exactly the accessibility failure this tool is built to catch before it ships. A less obvious case: a blue/purple pairing like #4C8DF6 and #8A2BE2, which looks like an unambiguous safe choice to most sighted designers since it avoids red-green entirely, still shifts under tritanopia (blue-cone deficiency, much rarer but not nonexistent) — the purple drifts toward a plain pink while the blue stays comparatively stable, a smaller but real shift that's worth checking specifically when a product's user base is large enough that even a rare condition affects a meaningful number of people.

When to use this tool

Use this specifically on your product's semantic/status colors (error, success, warning, info, and any category-coded data-visualization palette) before shipping — those are the pairings most likely to carry meaning through color alone, which is exactly what breaks under color-vision deficiency. It's also worth running on any chart or graph that uses more than two or three data-series colors, since categorical color scales are one of the most common places a whole cluster of colors (not just one pair) collapses together under a single dichromacy type, silently making an entire chart unreadable for a meaningful share of viewers even though each color looks perfectly distinct to someone with typical color vision. It's a complement to the Contrast Checker, not a replacement: contrast checking catches luminance-based legibility failures, this catches hue-based confusability failures, and a real accessibility pass needs both checks run together.

Precision & accuracy

The Machado et al. matrices are applied with full floating-point precision in linear-light space before converting back to 8-bit sRGB for display, which avoids the visible banding/error accumulation that applying the matrix directly to gamma-encoded 8-bit values would introduce — a subtle implementation detail that separates an accurate simulator from a merely plausible-looking one. It's also worth being precise about what these matrices do and don't model: they simulate complete dichromacy (one cone type entirely absent), the more severe and less common end of color-vision deficiency, while the majority of people with a color-vision difference have anomalous trichromacy (a cone type that's present but shifted in sensitivity, not missing) — the simulation here is a genuine worst-case reference, useful precisely because a design that survives the worst case will also work for the more common, milder anomalous-trichromacy cases, even though it doesn't render those intermediate cases directly.

FAQ