Color contrast checker
Check WCAG 2.1 and APCA contrast for two colours — or drop a screenshot and see exactly where thin strokes make text hard to read. All local, no upload.
How to capture solid material
Browser zoom does not increase resolution, and snipping tools on HiDPI displays often capture logical instead of physical pixels. Use Chrome DevTools → Elements panel → right-click the element → "Capture node screenshot", or Firefox's right-click screenshot — both capture at device resolution.
| # | Occurrences | Stroke width | WCAG nominal → effective | APCA nominal → effective |
|---|
Note — the analysis runs entirely locally in your browser; the screenshot never leaves your device. Clicking a table row steps the loupe through that group's occurrences.
Why a passing WCAG ratio can still be hard to read
Every contrast checker on the web takes two colour values and returns a ratio. That number is honest about colours — and blind to everything else. A 4.5:1 pairing that sails through WCAG AA can be genuinely hard to read when the typeface is a thin weight at a small size, because what reaches your eye is not the nominal text colour: it is the anti-aliased blend of text and background that the rasterizer actually painted. The thinner the stroke, the more of each letter consists of those washed-out edge pixels, and the effective contrast quietly drops below what the two hex values promised.
That is the gap this tool closes. Alongside the classic two-colour check, it accepts a screenshot of your real interface and measures what was actually rendered — where the strokes are thinnest, and what the effective contrast is at exactly those spots. A design that passes on paper and fails on screen shows up immediately, with coordinates, stroke widths in pixels and the measured contrast for each critical point.
WCAG 2.1 vs APCA — what the two numbers mean
The WCAG 2.1 ratio is the established legal benchmark: 4.5:1 for normal text (AA), 3:1 for large text, 7:1 for AAA. It treats a dark-on-light pairing and its light-on-dark inverse as identical, which human vision does not — light text on a dark background reads worse at the same ratio. APCA (Accessible Perceptual Contrast Algorithm), the candidate model for WCAG 3, fixes this with a perceptual score called Lc that is polarity-aware and tuned to how contrast sensitivity really works. As rough guidance, Lc 90 suits body text, Lc 75 is the target for normal reading text, Lc 60 covers large or bold text, and anything below Lc 45 is fit for decorative elements at best.
This checker always shows both: the WCAG ratio you need for compliance work today, and the APCA Lc that better predicts what people will actually experience. When the two disagree — a pairing that passes WCAG but scores a weak Lc — trust the pessimistic one and adjust the colours.
What thin strokes and anti-aliasing do to text
A rasterizer cannot draw a 1.5-pixel stroke. It draws one solid pixel and shares the remaining half among neighbouring pixels as intermediate shades between text and background. On a thick stroke those blended edges are a small fraction of the letter; on a hairline weight they are most of it. The result is text whose measured contrast — sampled from the actual pixels — can be dramatically lower than the declared colour pair, especially on standard-resolution displays, at reduced screen brightness, or after an operating system scales the interface.
The screenshot analysis makes this measurable. It binarizes the image against the detected background, runs a distance transform to find the centreline of every stroke, and reports the thinnest point of each connected shape together with the effective contrast sampled there. Strokes of 3 pixels and more with an Lc of 60+ rate green; anything under 2 pixels or below Lc 45 rates red, because at that width the anti-aliasing has consumed the letterform. For dependable numbers, capture the screenshot at 2× (Retina) resolution and check the interface at the size users really see.
Who is affected — and how to fix a failing result
Low effective contrast is not an edge case. Contrast sensitivity declines steadily with age even in healthy eyes, and it drops sharply with cataracts, macular degeneration, glaucoma and diabetic retinopathy; astigmatism additionally blurs thin strokes into their background. Situational factors stack on top — sunlight on a phone, night-shift colour filters, cheap panels at low brightness. Setting text in all caps makes it worse still, because uppercase removes the ascenders and descenders that help the eye separate letters that are already faint.
The fixes follow directly from the measurements. If the thinnest strokes are under 2 pixels, increase the font weight — moving body text from 300 or 400 to 500 usually resolves it without redesigning anything. If the effective contrast is the problem, darken the text colour (or lighten it on dark backgrounds) until both the WCAG ratio and the Lc are comfortable. If the type is simply small, increase the size before touching anything else. Re-run the screenshot after each change; the export image documents the before-and-after for your team.
Privacy by design
All processing happens inside your browser. Your files never reach a server — there is nothing to store, transmit or share.
Learn more in our privacy policyFrequently asked questions
It is free with no sign-up, and nothing is uploaded. Both the colour check and the full screenshot analysis run inside your browser — you can disconnect from the internet after the page loads and everything still works.
As a rule of thumb Lc 90 is ideal for body text, Lc 75 is the working target for normal reading text, Lc 60 is acceptable for large or bold text, and values below 45 should not carry text at all. APCA is polarity-aware, so light-on-dark and dark-on-light score differently — unlike the WCAG ratio.
Because the ratio only describes the two nominal colours. At thin font weights, anti-aliasing blends most of each stroke with the background, so the contrast actually rendered on screen is lower than the declared pair. The screenshot analysis measures those real pixels at the thinnest spots — that is the value your readers experience.
Stroke widths are measured in screenshot pixels. At 1× a normal font stroke is only one or two pixels wide, which leaves the measurement little to work with; at 2× the same stroke spans twice the pixels and the analysis becomes much more reliable. Text under about 10 px in the image triggers a low-resolution warning.
Yes — every connected shape that contrasts with the background is measured, including line icons and UI graphics. That is useful, because a 1-px-stroke icon has exactly the same legibility problem as hairline text. Photos and gradient regions are detected and flagged as unreliable instead of producing false numbers.
No. Contrast and stroke width are two important factors among many — keyboard navigation, focus states, semantics and screen-reader support need their own testing. This tool tells you quickly and precisely whether your text is physically legible; for conformance claims under WCAG, the EAA or similar rules, combine it with a complete audit.