WCAG Contrast Checker Calculator

This WCAG contrast checker compares two HEX colours and calculates the contrast ratio between foreground text and background colour.

It shows whether the colour pair passes common WCAG AA and AAA thresholds for normal text and large text, with a live preview so obvious readability issues are visible before you copy the colours.

Use it for UI colours, button text, headings, documentation examples, design-system tokens, and quick accessibility checks before a fuller design review.

Dark slate text such as #1F2937 on a white background has a strong contrast ratio and generally passes normal-text thresholds. A pale grey on white can look subtle in a mockup but fail the same ratio check immediately.

Large text has a lower contrast threshold than normal body text because thicker and larger letterforms are easier to read. The calculator shows both so you can tell whether a colour pair is usable only for large headings or also for paragraph text.

The preview helps with human judgement, while the ratio gives the objective check. Use both: a pass result is useful, but you still need to inspect the actual component size, weight, state, and context.

The color picker and converter is for converting HEX, RGB, HSL, HSV, and quick black-or-white contrast cues. This page is for comparing a specific foreground and background pair against WCAG-style contrast thresholds.

That distinction matters when you already know the two colours used in a button, card, chart label, code sample, alert, or navigation item. A conversion tool tells you what the colour is; a contrast checker tells you whether the pair has enough luminance separation.

For layout values around the colour system, pair this with the CSS clamp calculator, REM to PX converter, or viewport unit calculator.

Contrast is necessary, but it is not the whole accessibility check. Font size, font weight, focus styles, disabled states, hover states, icon labels, motion, semantic HTML, and keyboard behaviour all matter.

Do not rely on colour alone to communicate meaning. A red error state, green success state, or coloured chart series should also have text, icons, patterns, labels, or another non-colour cue.

Use this calculator as a quick numeric screen, then test important UI in the actual product with the real text, type size, component state, and surrounding background.

Start with the exact foreground and background colours used in the component, not approximate palette names.

Check normal text and large text separately because the ratio threshold is lower for large or bold text.

Use the preview to catch obvious readability issues, then verify the real component with its actual font size, weight, padding, state, and background.

If the pair fails, adjust one colour at a time so the design change is easy to review.

A passing contrast ratio does not guarantee a fully accessible interface. Keyboard access, focus indicators, labels, semantic markup, motion, error messages, and responsive behaviour still matter.

Colour should not be the only signal. Errors, success states, chart categories, selected tabs, and warnings should also use text, icons, shapes, labels, or patterns.

Disabled states and placeholder text often need separate review because teams sometimes make them much lighter than normal body text.

For production accessibility reviews, use this as a quick numeric check alongside real-device testing and broader accessibility tooling.

This page should target WCAG contrast checker, color contrast checker, accessibility contrast checker, contrast ratio calculator, and AA AAA contrast searches.

It compares two solid HEX colours with the standard relative luminance contrast formula and reports common WCAG 2.x AA and AAA text thresholds.

It does not evaluate transparency, gradients, images, focus order, screen-reader behaviour, keyboard access, legal compliance, or full accessibility conformance.

A common workflow is to paste or enter a real sample, review the output, then adjust one setting at a time. This makes it easier to see exactly what changed and avoid copying an incorrect result.

For developer and web-design tasks, test the result in the place it will actually be used. Encoded text, CSS values, parsed URLs, timestamps, and generated strings can behave differently depending on the target system.

Check formatting, character escaping, units, timezone assumptions, and browser support before using the output in production. Small formatting differences can break code, URLs, data files, or layouts.

Avoid pasting private secrets, passwords, API keys, or personal data into tools unless you are comfortable with where that data is processed. These calculators are designed for convenient local checks, not secure secret handling.

Design and frontend work often gets messy when values are guessed by eye. A calculator can turn a layout idea into a concrete number, whether you are scaling media, choosing colour formats, planning gaps, or building fluid CSS.

The best use is comparison. Try the value at small, medium, and wide sizes, then decide whether the output still feels balanced inside the actual component rather than only in the calculator preview.

Check the surrounding styles before copying the result. Padding, box sizing, container width, inherited font size, and browser rounding can all change how a mathematically correct value looks on the page.

Keep a short note of the design reason for the number if the value will live in production CSS. Future edits are easier when another person can see whether the value came from a ratio, a breakpoint, a spacing rule, or a one-off layout fix.