Color-Blind Simulator

What is this for?

Roughly 1 in 12 men and 1 in 200 women has some form of color vision deficiency. If your game uses red and green as the only difference between "enemy" and "ally", or between "low HP" and "full HP", a non-trivial fraction of your players literally cannot tell them apart. The fix is to add a non-color cue (shape, label, icon) — but first you need to know which colors actually collide. This tool runs your screenshot through the four canonical color-blindness simulations, so you can see what's happening before someone files a 1-star review titled "everything looks the same to me".

The four types simulated

• Protanopia — no functional L-cones (red-sensitive). Reds darken and shift toward yellow; reds and greens become hard to distinguish. ~1% of males, very rare in females.
• Deuteranopia — no functional M-cones (green-sensitive). The most common type — about 5% of males. Reds and greens collide; the world skews toward yellow-brown.
• Tritanopia — no functional S-cones (blue-sensitive). Blues and yellows collide. Very rare (<1%, roughly equal between sexes).
• Achromatopsia — no color vision at all, just luminance. Vanishingly rare in its full form (<0.01%). Worth checking because if your UI works under achromatopsia, it works under everything else. This is also how your design looks to anyone using a monochrome display or a colorblind-mode that strips chroma.

How the simulation works

Each variant applies a 3×3 matrix transform to the RGB values of every pixel. The matrices are LMS-space approximations from the Brettel & Viénot 1997 paper, the standard reference for dichromat simulation. They are not perfect — true simulation requires more than a linear transform in sRGB — but they're a very good first-pass tool for design review. If a UI element survives the simulation, it almost certainly survives reality; if it doesn't survive, you have a problem.

What to check

• Status colors. Red HP bar vs green HP bar — collide under deuteranopia. Use shape change (segmented), animation (low-HP flash), or an icon.
• Faction colors. Red enemy markers vs green ally markers — same problem. Use icon shape or outline style.
• Map markers. If players hunt down colored objectives, ensure each color has a unique icon shape.
• Stat bars. Mana (blue) and HP (red) usually stay distinct under all four. Mana (blue) and stamina (yellow) collide under tritanopia — verify.
• UI accents. Buttons that change colour to indicate state need a second cue: border thickness, icon swap, or a text label.
• Damage type icons. Fire (red) and poison (green) almost always collide for deuteranopes if the only difference is the colour of the same flame shape.

Common gotchas

• The simulation is approximate. Real-world dichromats may see colors slightly differently, and there are partial deficiencies (anomalous trichromacy — protanomaly, deuteranomaly) that aren't simulated here. Use this for design review, not medical assessment.
• Difference highlights aren't a bug list. Some shift is expected (the whole point is that some colors map differently). What matters is whether a specific gameplay-critical signal still reads as different. Toggle the highlight to spot collisions, then judge by eye.
• Test moving content too. Static screenshots miss animation-based cues. Run a short gameplay clip frame-by-frame, or just play with the difference toggle on a representative still.
• Files stay local. Image decoding, transform, and download all happen in the browser. Nothing is uploaded. If your screenshot contains a beta logo or unannounced art, that doesn't leave the page.
• Achromatopsia ≠ "convert to grayscale". It's the same coefficients (Rec. 601 luminance), so yes, in practice that's what you see. The reason it's worth checking is to catch UI that relies on hue distinction with no luminance contrast.