Useful results start with clear limits.

1. Measurable color contrast

For solid, opaque HEX colors, the Contrast Checker converts each sRGB channel to a linear-light value, combines the channels using relative luminance weights and compares the lighter and darker luminances. The WCAG 2.x contrast formula is (Llighter + 0.05) ÷ (Ldarker + 0.05). A result of 1:1 means equal luminance; the theoretical maximum is 21:1 for black against white.

For example, text #223344 on #FFF9F2 measures 12.35:1 in our live calculation. That exceeds the 4.5:1 WCAG 2.x AA minimum for normal text. Large-text requirements, non-text UI controls, typography and keyboard states involve additional criteria. Contrast alone does not certify an accessible page.

The Contrast Audit Worksheet can suggest a replacement foreground for a failing opaque HEX pair. It checks both a darker and a lighter path from your current foreground, measuring the actual 8-bit output against the selected WCAG 2.x threshold, then prefers the path with the smaller difference in OKLab color space. Your background remains untouched, and nothing changes until you select Apply suggestion. An Undo action restores the prior foreground. This is a color-pair repair suggestion, not a claim that the suggested color preserves your exact brand identity, or that the full UI meets accessibility requirements.

Reproduce the result in the Contrast Checker →

2. Palette harmonies are a starting point

The Generator converts your base HEX color into hue, saturation and lightness, then varies the supporting swatches according to the selected harmony. The chosen base stays unchanged in the center swatch. An analogous option keeps related hues close together; complementary and triadic options spread supporting hues more widely; monochromatic stays near one hue.

These arrangements describe relationships on a color wheel. They do not guarantee emotional impact, readability, brand originality or color-vision accessibility. In a working UI, map the colors to roles such as background, text, surface, primary action and status first. Then check every foreground/background pairing in its real context. Use the multi-pair contrast audit worksheet to organize those checks.

Compare harmony modes in the Generator →

3. Image sampling and local processing

The Image Color Picker reads a user-selected file with browser APIs and samples pixel colors locally. The logo, screenshot and stylesheet tools likewise perform their analyses in the browser without a ColorThemePicker processing server. A file selected for one of these tools is not a publication, cloud backup or website upload. When you explicitly save a local project, your browser may retain related data in site storage until you clear it or the browser evicts it.

Image results can change due to transparency, embedded color profiles, resampling, compression or where you click. The manual picker reports the browser-decoded pixel at your selection; automatically suggested palettes cluster similar pixels and may resize very large images, so they are estimates rather than exact brand-color recovery. CMYK values are generic mathematical conversions, not printer-ICC-profile measurements. For transparent photos in the Image Contrast Lab, calculations use the same declared dark fallback backing as the preview and exported overlay CSS. Photos also contain lighting and shadow, so the most frequent pixel is not automatically a good text or brand color. Verify sampled values before applying them to a design.

Read the full privacy policy →

4. Source audits are not a rendered-browser audit

CSS Migration, Website Doctor, Design System Lab and Style Intelligence analyze selected code and files to identify potential colors, semantic roles, conflicts or inconsistencies. Their reports are helpful starting evidence, not proof that every selector resolves to the same color in production. CSS imports, variables, media queries, pseudo-elements, injected styles and image backgrounds may affect actual results.

Website previews sanitize or isolate user markup for safer review; they are not a replacement for running the real application. Keep your source under version control, approve changes selectively and compare actual pages at phone, tablet and desktop widths before deployment.

Explore Website Doctor →

5. A repeatable verification checklist

1. Readability: test body text, buttons, form labels, hints and error messages against their actual backgrounds.
2. Interaction: review focus rings, selected states, hover feedback, disabled controls and keyboard navigation.
3. Responsive behavior: compare full-page layout, not just an isolated card, at narrow and wide widths.
4. Alternative signals: charts, statuses and errors must remain understandable without color alone.
5. Implementation: export named tokens, review the CSS cascade and check the final rendered build.

For a walkthrough with specific values, see our three worked design examples. The examples are fictional exercises clearly marked as such; we do not invent client results or accessibility certifications.

6. Corrections and accountable publishing

Documentation is updated alongside product releases. If you spot a broken interaction, incorrect ratio, inaccessible page or misleading explanation, please send the page URL and steps to reproduce through our contact page. The educational content is provided for design planning, not as professional legal, security or accessibility advice.