Color Blindness Simulator for Protanopia, Deuteranopia, and Tritanopia
Preview how one color may appear with protanopia, deuteranopia or tritanopia: #3A86FF under deuteranopia becomes #5751DB. Check status colors and chart series before two of them blur into one. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Color
- #3A86FF
- Type
- Deuteranopia
- Simulated color
- #5751DB
This color blindness simulator transforms one hexadecimal sRGB color with a standard fixed matrix for protanopia, deuteranopia, or tritanopia. It returns the normalized source color, the selected vision type, the simulated hexadecimal color, and its red, green, and blue channel values. The result is a practical approximation for early design checks, palette comparisons, documentation, and automated quality workflows. It does not diagnose vision or reproduce every person's perception, but it makes potentially confusing color shifts visible before a design reaches users.
Choose a source color and simulation type
Start with a color written as a hexadecimal sRGB value, using either the compact three-digit form such as #F80 or the full six-digit form such as #FF8800. Then select protanopia, deuteranopia, or tritanopia. Protanopia models the absence of functional long-wavelength cone response and often changes relationships involving red.
Deuteranopia models the absence of functional medium-wavelength cone response and commonly affects distinctions involving green. Tritanopia models the absence of functional short-wavelength cone response and can alter blue-yellow relationships. The returned source value is expanded and normalized to uppercase, so compact input remains easy to compare with the simulated result.
Understand how the approximation is calculated
The simulator first converts the hexadecimal text into three integer sRGB channels from zero through 255. It then selects the fixed 3-by-3 matrix associated with the requested color-blindness type. Each output channel is the weighted sum of the original red, green, and blue channels.
The calculated values are rounded to the nearest integer, constrained to the valid channel range, and formatted as a six-digit hexadecimal color. This is a deterministic matrix approximation: identical inputs always produce identical outputs, with no network request, random choice, user profile, or device-dependent state. That consistency is useful for repeatable audits and snapshots.
However, a single simulated swatch is not a complete accessibility verdict. Real color vision varies, display calibration varies, and surrounding colors influence perception. Treat the transformation as a way to reveal likely shifts and collisions.
Pair it with contrast measurement, non-color cues, labels, patterns, and testing across complete interface states before making a final accessibility decision.
Use the result in an accessible design workflow
Compare the returned simulated color with other transformed colors from the same palette, especially colors that communicate status, selection, validation, or chart categories. Two source colors that look clearly different may move closer together under one simulation. If they become difficult to distinguish, revise hue, lightness, saturation, borders, icons, text, or patterns rather than relying on color alone.
Stable output makes regression reviews straightforward when a design system changes. Remember that this capability evaluates a color transformation, not contrast between foreground and background and not an entire rendered page. A strong review combines the simulation with contrast checks and human-centered usability testing.
Document which matrix type was used so teammates can reproduce the result and understand why a palette decision changed.
What you can do with it
Review design-system tokens
Transform semantic palette colors under all three supported types before approving a new token release.
Check chart categories
Compare simulated series colors and add labels, markers, or patterns when hue alone may not separate them.
FAQ
Which color-blindness types are supported?
Protanopia, deuteranopia, and tritanopia are supported. Any unrecognized type returns an invalid-input error.
What color formats can I provide?
Use hexadecimal sRGB in #RGB or #RRGGBB form. Color names and values with alpha channels are not accepted.
Is this a medical diagnosis or an exact view of perception?
No. It is a matrix-based approximation for design analysis, not a diagnostic tool or an exact model of every person's vision.
Does a simulated color prove that a design is accessible?
No. Also check contrast, provide cues beyond color, review complete interface states, and include appropriate user testing.
What does #3A86FF look like with deuteranopia?
The simulator returns #5751DB, with red 87, green 81 and blue 219. Run the other colors of your palette through the same type and compare: pairs that move close together need another cue, such as a label or pattern.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/color/blindness-simulate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"color":"#3A86FF","type":"deuteranopia"}'const res = await fetch("https://api.kit.forhosting.com/color/blindness-simulate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"color": "#3A86FF",
"type": "deuteranopia"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/color/blindness-simulate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"color": "#3A86FF",
"type": "deuteranopia"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/color/blindness-simulate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"color":"#3A86FF","type":"deuteranopia"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"color":"#3A86FF","type":"deuteranopia"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/color/blindness-simulate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"color": "#3A86FF",
"type": "deuteranopia"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "color.blindness_simulate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Choose a source color and simulation type
The endpoint rejects any other type instead of silently guessing, which keeps batch tests and design-system checks dependable. It also rejects color names, missing hash signs, alpha channels, and malformed hexadecimal strings. Keeping the accepted format narrow makes the same input behave identically in a browser form, an API request, a test suite, or a build pipeline.
Use the result in an accessible design workflow
For automated work, call the endpoint once for each palette entry and each supported type, then store the normalized hexadecimal and RGB outputs beside the original tokens. The API price is $0.002 per item, while the browser experience can support quick individual checks.
Integration use cases
Automate palette regression tests
Generate stable transformed values in a build process so reviewers can spot accessibility regressions after color changes.
Technical questions
How much does an API simulation cost?
Each item costs $0.002. The calculation is deterministic and does not contact an external service.