Color Blindness Simulator
Preview how one chosen color may appear to people with common color vision deficiencies. The simulator updates instantly, so you can test alert colors, brand accents, chart lines, and interface states before those choices reach real users.
See one color through different kinds of color vision
This calculator is small on purpose: it focuses on one decision that comes up constantly in design and communication work. You have a color in mind, or you already use one in a product, and you want to know whether that color keeps its identity when a viewer does not perceive red, green, or blue information in the usual way. A fast simulation will not replace testing with people, but it does help you catch fragile choices early. That is often enough to prevent a warning button, status chip, map marker, or chart legend from becoming ambiguous.
The input is simply a source color. The output is four swatches: the original color, then approximate transformed versions for protanopia, deuteranopia, and tritanopia. Protanopia is associated with absent or strongly reduced long-wavelength cone response, deuteranopia with absent or strongly reduced medium-wavelength response, and tritanopia with absent or strongly reduced short-wavelength response. In everyday terms, these modes can make some pairs of colors compress toward one another even when they look comfortably different to a person with typical color vision.
That compression is the practical reason a simulator matters. Many interfaces rely on color as a shortcut for meaning. Green may signal success, red may signal error, orange may mean warning, and blue may mark a link or selected state. If two of those choices collapse into a similar olive, brown, gray, or muted blue under a deficiency mode, the interface is asking users to guess. This page lets you preview that risk immediately and then copy the resulting hex summary for a design review, accessibility note, or testing checklist.
What the single input represents
The color picker accepts one hex color, such as #FF0000 for bright red or #2F80ED for a strong interface blue. There are no units to convert and no hidden settings to tune. Think of the chosen color as the exact paint you are applying to one design element: a primary button fill, a data point, a status badge, a line in a chart, a pie-slice segment, or the accent behind white text. When you move the picker, the simulator treats that source color as the only thing changing while the vision mode changes around it.
That narrow focus is useful because it matches how many real design choices are made. Teams rarely redesign an entire palette in one moment. They decide whether a single proposed color is safe enough for a particular job. If you are reviewing a brand system, you can step through several colors one by one and compare the resulting summaries. If you are auditing a product, you can inspect problem areas such as success versus error states, active versus inactive tabs, or multiple lines in a chart legend.
The copy button exports a plain-text summary of the current palette so you can paste it into a ticket, email, issue tracker, or handoff document. That tiny workflow improvement matters because accessibility work is easier when you can show the before-and-after values clearly. Instead of saying a color looked wrong, you can show the original hex and the three simulated outputs and explain exactly which mode caused the collapse.
How to use the simulator well
Start by choosing the exact source color you want to test. The first swatch shows the untouched color. The next three swatches show how that source color is remapped under each deficiency mode. Read the result as a comparison tool, not as a medical diagnosis. The question is not whether the transformed swatch is beautiful on its own. The question is whether it still looks distinct enough for the job you assigned to the original color.
In practice, the most useful habit is to test neighboring decisions, not isolated colors. If you use one red badge for error and one green badge for success, preview both colors in separate runs and ask whether the transformed results drift toward the same region. If they do, add shape, text, iconography, border treatment, or a new hue choice so users are not forced to rely on color alone. The same idea applies to charts: lines, bars, or points should remain separable even after the simulation changes them.
It also helps to think about context. A color can be recognizable in isolation but still fail against a background. Saturated yellow may stay yellow, yet disappear against white. Dark blue may survive a simulation but merge into a black navigation bar. This calculator focuses on the color shift itself, so after you preview the swatch you should still inspect the actual interface context with contrast and labeling in mind.
How the simulator turns one color into four swatches
Under the hood, the page reads the source color as three RGB channel values: red, green, and blue. Each vision mode then applies a fixed three-by-three matrix to those channels. The matrix does not guess a name for the color or use artificial intelligence. It simply recombines the red, green, and blue intensities according to coefficients that approximate how the source color would be perceived under a given deficiency model.
The generic structure is still the same as any calculator: take inputs, apply a function, and show a result. Here, the input vector happens to be the three color channels. That is why the page preserves the general form below. You can read it as one result derived from several measured inputs, where the source red, green, and blue values are the inputs and the displayed swatch is the result.
For color simulation, those weighted combinations are especially important. Each transformed channel is a sum of contributions from the source channels. In plain language, the new red output might still contain some of the old red channel, but it may also borrow information from green or blue. That is why reds and greens can converge under protanopia or deuteranopia: the matrix changes how much each original channel contributes to the final displayed value.
In this simulator, the weighting terms are the matrix coefficients for protanopia, deuteranopia, and tritanopia. Because each row of the matrix blends the original RGB channels differently, some hues shift only slightly while others move a great deal. Strong reds and greens are often the most revealing examples, but medium-complexity colors such as olive, teal, coral, mauve, and brown can also surprise you because their identity depends on several channels at once.
One more detail is worth knowing: these are approximate transformations meant for quick review. They are useful because they are consistent. If you test the same hex value twice, you get the same simulated outputs twice. That consistency makes the tool good for side-by-side design decisions even though real human perception is more varied than any single matrix can capture.
Worked example: bright red under three deficiency modes
Suppose you start with #FF0000, a strong pure red that many teams use for destructive actions or urgent alerts. In normal vision it reads as unmistakably red. Under the simulator's matrices, however, that same source color shifts to roughly #918E00 for protanopia, about #9FB300 for deuteranopia, and about #F20000 for tritanopia. The exact rounded hex values come from the live calculator, but the practical takeaway is the same: for some viewers, a bold red warning can move toward a dull olive or yellow-green impression instead of staying clearly red.
If your interface also uses green for success, that example should make you pause. A red error state and a green success state can move toward each other in the very modes where users most need those signals to stay distinct. The fix is not always to abandon color. Often the better fix is to combine color with text, icons, outlines, ordering, or patterns so the state remains obvious even when hue information compresses.
This is also why the simulator is useful in education. It demonstrates that accessibility problems are not abstract rules imposed after design. They grow out of the actual math of perception and display. When a source color is transformed, the loss is not random. It follows from how much the original design relied on a channel that becomes less informative in a given mode.
What to look for when the swatches update
When you change the source color, look for three kinds of warning signs. First, ask whether the transformed swatches bunch together into a narrow family of muted tones. Second, ask whether the transformed color loses its intended emotional signal, such as danger, success, or emphasis. Third, ask whether the new color would still stand apart from nearby interface colors and from its background. If any answer is no, the color deserves a second pass.
The table below shows common situations where this calculator is especially helpful. It is not a full rulebook. It is a practical reminder of what to inspect once the four swatches appear.
| Design situation | What the simulator may reveal | Useful response |
|---|---|---|
| Error vs success colors | Red and green may drift toward similar muddy or olive tones under protanopia and deuteranopia. | Add icons or text labels, and consider shifting one state toward blue or using stronger lightness differences. |
| Chart lines and legend keys | Several distinct brand colors can compress into a small cluster, making series hard to track. | Use line styles, markers, labels placed directly on data, or a palette with larger lightness separation. |
| Buttons and selected states | A chosen accent may remain saturated but lose contrast against nearby surfaces. | Check the actual background, border, and text treatment after previewing the hue shift. |
| Maps and status badges | Meaningful categories can become visually similar when hue does too much of the communication work. | Pair color with shapes, symbols, patterns, or position so the map or badge still reads correctly. |
A good rule of thumb is that color should support meaning, not carry all of it alone. If the swatches make two categories look close, treat that as a signal to add another cue. Accessibility usually improves fastest when teams reduce dependence on any single visual channel.
How to interpret the text result
The result box gives you a compact sentence listing the normal hex plus the three simulated hex values. That summary is useful for documentation because it turns a visual preview into a precise record. If a teammate later asks why a color was rejected, you can show that the chosen red became an olive-like value under a specific mode, or that two proposed accents produced nearly identical transformed outputs.
Interpreting the result is simpler if you ask two direct questions. First, does the transformed value still feel meaningfully different from neighboring colors you use for other states or categories? Second, would the transformed value still work with the surrounding background and text? If the answer to either question is uncertain, run another color and compare. Small hue shifts or changes in lightness can produce much safer outcomes than you might expect.
Because the simulator responds instantly, it is excellent for quick scenario testing. Try a saturated version of a color, then a darker one, then one shifted slightly toward blue or yellow. Watch which direction makes the transformed swatches separate more clearly. That kind of exploration helps you build an intuition for accessible palette choices rather than memorizing one-off rules.
Limits and assumptions
This page is a fast approximation tool, not a clinical model of every visual experience. Real perception varies by person, display quality, ambient light, adaptation, color size, surrounding colors, and whether a deficiency is complete or partial. The matrices used here are standard enough to be useful, but they do not capture every severity level or every contextual effect that matters in a real interface.
The calculator also does not replace a contrast checker. A transformed swatch can still fail if the text laid over it is too light, if the background is too similar, or if important information is encoded only by color. Likewise, a color can pass contrast standards yet remain confusing if two categories look too close together. Accessibility decisions usually need both checks: contrast and distinguishability.
The most productive way to use the simulator is as an early warning system. If a color looks risky here, treat that as a prompt to revise. If it looks acceptable here, treat that as a positive sign and then continue with broader testing in context. That workflow keeps the tool honest and useful: it helps you screen ideas quickly without pretending that one transformed patch can answer every accessibility question by itself.