Free Accessible Color Palette Generator

What is an accessible color palette generator?

An accessible color palette generator is a tool that helps you assemble a set of colors for a website, app, or print design where every pair of colors meant to be displayed together (text on background, button on canvas, label on field) meets the WCAG contrast requirements. The point is to catch low-contrast combinations at design time rather than at audit time. You add colors to a palette, the tool computes the contrast ratio between every pair, and it labels each pair AAA pass, AA pass, or fail. You iterate until every pair you actually intend to use passes.

The contrast ratio is a number between 1:1 (identical colors, invisible) and 21:1 (black on white). WCAG 2.2 Success Criterion 1.4.3 requires 4.5:1 for body text at standard size (Level AA), 3:1 for large text (24px+ regular or 18.66px+ bold), and 4.5:1 for graphical elements and UI controls (SC 1.4.11). WCAG AAA raises body text to 7:1 and large text to 4.5:1. Most public-facing websites must meet at least AA per ADA, EAA, AODA, and similar laws; government sites in many jurisdictions must meet AAA.

This tool runs in your browser. You pick colors with the color picker, the tool computes the relative luminance and contrast ratios using the WCAG-specified formula, and a grid shows every pair's status. You can export the final palette as CSS custom properties (var(--brand-primary)), HEX list, Tailwind config snippet, or JSON for design tokens. Nothing is uploaded; the entire palette stays on your device.

What is inside the tool

The top of the tool is a color picker plus an add-to-palette button. Pick a color, name it (Brand Primary, Surface, Body Text, etc.), and add. The palette grows as a swatch list down the left side. You can edit any swatch, remove it, or drag to reorder. Predefined accessible palettes are available as starting points (high-contrast pairs, IBM Carbon-style designed palettes, Material Design 3 tonal palettes); pick one, then customize.

The contrast grid takes every pair of swatches and shows the contrast ratio plus a pass/fail badge for each WCAG level: AA-normal (4.5:1), AA-large (3:1), AAA-normal (7:1), AAA-large (4.5:1). A pair shown as 4.7:1 passes AA-normal but fails AAA-normal; a pair shown as 2.1:1 fails everything. Hover a cell to preview the pair as actual text. Sort the grid by ratio to spot the worst pairs first.

The export panel formats the palette in the way your toolchain expects: CSS custom properties for modern CSS, Sass variables for older pipelines, Tailwind theme config for Tailwind CSS, JSON design tokens (Style Dictionary, W3C Design Tokens Community Group spec) for cross-platform design systems, or just a HEX list for paste into Figma. Naming conventions are preserved; you can copy and paste directly into your codebase.

History and background

CIE colorimetry establishes scientific color (1931)

The International Commission on Illumination (CIE) published the CIE 1931 color space in 1931, the first formal mathematical description of how humans perceive color from electromagnetic spectra. Every modern color system (RGB, HSL, OKLCH, Lab, XYZ) builds on CIE 1931 either directly or through derived transformations. The relative luminance formula that WCAG uses to compute contrast is a CIE-derived calculation: it weights red, green, and blue channels by how strongly the human eye responds to each (green most, blue least).

WCAG 1.0 introduces contrast guidelines (1999)

The Web Content Accessibility Guidelines 1.0 (W3C, May 1999) introduced contrast as a formal accessibility criterion (Checkpoint 2.2: ensure foreground and background color combinations provide sufficient contrast). The first version was qualitative; the threshold was vague. WCAG 2.0 (December 2008) was the first to specify numeric contrast ratios using the WCAG relative luminance formula. The 4.5:1 and 7:1 thresholds in 2.0 have been kept unchanged through 2.1 (2018) and 2.2 (2023) because they balance readability across most disabilities (low vision, age-related contrast sensitivity loss, color blindness) with practical design constraints.

Color-coded design systems mature (2014 onwards)

Google's Material Design (2014), IBM's Carbon Design System (2015), and the broader rise of design tokens (Salesforce 2014, Atlassian 2016) all foregrounded accessible color as a system-level concern. Material Design 3 (2021) introduced tonal palettes (a 13-step lightness ramp per hue) explicitly designed so that any tone 600+ on the lightness scale passes 4.5:1 contrast on white. This shift made accessible-by-default palettes standard practice in modern design systems, replacing the older brand-first-accessibility-second approach.

APCA proposed as a more accurate alternative (2019 onwards)

The Accessible Perceptual Contrast Algorithm (APCA) was proposed by Andrew Somers starting in 2019 as a more perceptually accurate replacement for WCAG's contrast formula. WCAG contrast over-rates the readability of light colors and under-rates dark text on dark backgrounds; APCA corrects these. WCAG 3.0 (the draft successor to 2.x, in development for many years now) is expected to adopt APCA or a similar improved algorithm. Until WCAG 3 is released and adopted in law, WCAG 2.x contrast ratios remain the legal and industry standard. This tool uses the WCAG 2.x formula.

Design tokens become the cross-platform standard (2020 onwards)

The W3C Design Tokens Community Group was formed in 2020 to standardize design tokens (named color, spacing, typography values that translate across CSS, iOS, Android, Figma, and other platforms). Tools like Style Dictionary, Tokens Studio, and the emerging W3C spec all rely on machine-readable token formats. Accessible color palettes increasingly ship as design tokens so that the same vetted palette is used everywhere, eliminating the failure mode where the website passes contrast but the mobile app does not.

OKLCH and perceptually uniform color spaces (2020 onwards)

CSS Color Module Level 4 (Candidate Recommendation 2024) added OKLCH, OKLab, Lab, LCH, and other perceptually uniform color spaces to native CSS. OKLCH (introduced by Bjorn Ottosson in 2020) is particularly useful for generating accessible palettes because equal lightness steps look equal to the eye, unlike HSL where steps in lightness produce uneven visual jumps. Modern palette generators (Leonardo from Adobe, Polychrom, this tool when set to OKLCH input mode) leverage these spaces to produce more visually consistent palettes that meet contrast targets at the same lightness level.

Practical workflows

Designing a new brand palette

Start with the brand color you must keep (the logo color, the marketing-team-blessed primary). Add it to the palette, then build out tints (lighter versions) and shades (darker versions) along with neutrals (white, surface, surface variant, text). Check every text-on-background pair against AA-normal. If your primary brand color fails on white, you have two options: use it only for large elements (logos, decorative accents) and pair body text with a darker variant, or compromise the brand color slightly. This tool surfaces those choices at design time.

Auditing an existing site's color decisions

Pull the color values from your existing design tokens (CSS custom properties, Tailwind config, Sass variables), enter them into this tool, and review the contrast grid. Common failures: muted gray text on white (often #999 or #aaa, which gives 2.8:1 or 2.5:1), brand-color buttons with white text where the button is mid-tone, link colors on busy backgrounds. Document the failures with their ratios and which WCAG criterion they violate; that documentation is the start of a remediation plan.

Choosing accent colors for charts and data viz

For data visualisation, you need accent colors that pass contrast against the chart background and that are also distinguishable from each other for users with color vision deficiency. Pair this tool with ColorBrewer (Cynthia Brewer, Penn State, 2002) which publishes palette designed to remain distinguishable under color blindness simulations. Run candidate palettes through both tools: contrast against background (this tool), distinguishability between palette colors (ColorBrewer or Viz Palette).

Building dark-mode complements to a light palette

Dark mode is not just inverted light mode; the contrast requirements still apply but the eye perceives light text on dark differently from dark text on light (the APCA debate is largely about this). Build the dark palette as a parallel set of named tokens (surface-dark, text-dark, accent-dark) and check every dark-mode pair against AA. Common dark-mode failures: pure white (#fff) on pure black (#000) causes halation (light bleeding), so designers often use #e5e5e5 on #121212; this still passes AA but is more comfortable to read.

Generating palette variants for different surfaces

Modern UIs have multiple surface levels (background, card, card-elevated, modal, popover). Each surface should pair correctly with every text and accent color used on top of it. Add each surface as a palette swatch and check every text color against every surface. The contrast grid quickly shows whether your text-on-modal pair fails when text-on-card passes (the modal usually has a slightly different background tint to indicate elevation, which can drop the contrast below AA without you noticing).

Compliance documentation for legal or audit submission

For ADA or EAA compliance documentation, you typically need to show that every color combination in your design system passes the relevant WCAG level. Export the palette plus the contrast grid as part of the accessibility statement or VPAT (Voluntary Product Accessibility Template) for your product. The exported JSON is structured enough to feed into automated compliance reports; the visual grid is good for human review.

Common pitfalls

Treating brand color as untouchable

The most common pattern: marketing insists on the corporate primary color, but it fails AA contrast on white. Options: use the brand color only for large or decorative elements (passes the more lenient 3:1 large-text bar), darken the color slightly for text use (most brands have flexibility for a darker variant), or change the body text color from black to a less harsh dark gray so the brand color reads as an accent. Tools like Leonardo (from Adobe) generate accessible variants of a brand color automatically; pair them with this tool for verification.

Using contrast as the only accessibility check

Passing contrast does not guarantee readability. A 4.5:1 ratio is the floor; some users (low vision, age-related contrast sensitivity loss, dyslexia) benefit from higher ratios. WCAG SC 1.4.6 (Contrast Enhanced, AAA) recommends 7:1 for body text precisely because 4.5:1 is the minimum, not the target. Combine high contrast with sufficient font size (16px+ for body), adequate line height (1.5x font size), and font choices that preserve letter shapes (avoid ultra-thin weights for body text).

Forgetting non-text contrast (SC 1.4.11)

WCAG 1.4.11 (added in WCAG 2.1, 2018) requires 3:1 contrast for UI components and graphical elements: form field borders, button outlines, icons, focus indicators. This is easy to miss because designers think contrast only applies to text. A clean form with subtle gray field borders on white may fail 1.4.11 even if all text passes 1.4.3. Audit every visual element that conveys meaning or state, not just text on background.

Mistaking large-text rules

WCAG's large-text threshold (3:1 instead of 4.5:1) applies to text that is 18pt or larger (around 24px), or 14pt bold (around 18.66px bold). Anything smaller is normal text and needs 4.5:1. Designers sometimes apply the 3:1 large-text rule to all heading levels, but an h5 at 16px is normal text by WCAG's definition. Check the rendered size, not the heading level. The bold modifier matters: 18px bold passes as large text; 18px regular does not.

Relying on color alone to convey information

WCAG 1.4.1 (Use of Color, Level A) is separate from contrast. Even with perfect contrast ratios, you cannot use color as the only indicator of state (red equals invalid, green equals valid, blue equals link). Pair color with a second cue: icon (warning triangle for errors), pattern (underline for links), or text label (Required next to mandatory fields). Color-blind users (about 8% of men, 0.5% of women) and users on grayscale monochrome screens rely on these secondary cues.

Forgetting hover, focus, and active states

A button passes contrast in its default state but the :hover style lightens it below the threshold; the :focus outline is a subtle gray that fails 3:1 against the button background; the :active state inverts colors and the new combination fails. Test every interactive state in your contrast grid, not just the default. The focus indicator in particular is critical (SC 2.4.7 Focus Visible, AA): if focus is not clearly visible, keyboard-only users lose their place on the page.

Privacy and data handling

The colors you add, the palette names, and the exported tokens all stay in your browser. The contrast calculations run in JavaScript on your machine; nothing is uploaded. This matters less for color palettes than for documents but still matters when the palette is part of an unannounced brand refresh or a confidential client project: you do not want it leaking to a third-party SaaS validator before launch.

Once the page is loaded, the tool works offline. You can disconnect from the internet, build the palette, run checks, and export. The exported tokens are downloaded directly via the browser's normal save dialog. Many cloud color tools (Coolors, Adobe Color, even some accessibility checkers) store palettes server-side and may use them for analytics or training; for confidential work, prefer client-side tools.

When not to use this tool

For full color-blindness simulation (use a dedicated tool)

Contrast is not the same as color-blindness compatibility. A palette can pass all contrast checks and still confuse a color-blind user (red and green at the same luminance look identical to a deuteranope). For color-blindness simulation, use the Absolutool Color Blindness Simulator or Adobe Color's accessibility view, both of which apply the actual deuteranopia, protanopia, and tritanopia color transformations. Run candidate palettes through both this tool and a simulator.

For generating color schemes from scratch (use Leonardo or Coolors)

This tool checks and audits palettes; it does not generate them from a single seed color. For palette generation from scratch (analogous, complementary, triadic, split-complementary schemes), use Adobe Color, Coolors, or Leonardo (which generates accessible variants of a brand color). Generate with those tools, then validate with this one. Leonardo specifically generates colors targeted at specific contrast ratios, which is the natural input format for this tool's verification step.

For APCA-based contrast (when WCAG 3 ships)

This tool uses the WCAG 2.x contrast formula, which is the current legal and industry standard. If you specifically need to design for APCA (the proposed WCAG 3 algorithm), use the APCA Contrast Calculator from Myndex Research. APCA produces different (and arguably more perceptually accurate) ratings, especially for dark-on-dark and light-on-light text. Until WCAG 3 is ratified and adopted in law (likely several years away), WCAG 2.x is what compliance auditors will check.

For full WCAG audits (use a comprehensive tool)

Contrast is one criterion among dozens. For a complete accessibility audit, use axe DevTools, Lighthouse, WAVE, or a paid solution like Tenon or PowerMapper. These check contrast, alt text, ARIA, form labels, focus order, heading structure, and many more in a single pass. Use this tool during palette design, and the comprehensive tools during integration testing.

More questions

What is the difference between AA and AAA contrast?

AA is the standard, legally required by most accessibility laws (ADA, EAA, AODA, etc.) and what every public-facing site should meet. AAA is more stringent: 7:1 for body text, 4.5:1 for large text. AAA is generally required only for high-stakes content (government websites in some jurisdictions, medical and legal information, content for users with low vision as the primary audience). Designing for AAA is restrictive; few brands can meet it without significant color limitations. Aim for AA by default and AAA where the content audience justifies it.

Why does WCAG use 4.5:1 specifically?

The 4.5:1 threshold was chosen so that text remains readable for users with 20/40 vision (the threshold for legal blindness in many jurisdictions) without assistive magnification. It is also approximately the contrast ratio at which color-vision-deficient users can reliably distinguish foreground from background. The number is calibrated empirically from vision research; it is not arbitrary. AAA's 7:1 corresponds roughly to 20/80 vision, accommodating significantly more disability.

How does the contrast formula work?

Convert each color from sRGB to relative luminance using the formula: gamma-correct each channel (R, G, B) by applying a piecewise function (linear for low values, exponential for high), then weight by 0.2126 R + 0.7152 G + 0.0722 B (the relative human-eye sensitivity to each channel). The contrast ratio between two colors is (L1 + 0.05) / (L2 + 0.05) where L1 is the lighter luminance and L2 the darker. The 0.05 offset accounts for ambient screen reflection. The result is a number between 1 (identical) and 21 (max).

Should I worry about contrast for placeholder text in form fields?

Yes. Placeholder text counts as text under WCAG and must meet 4.5:1 contrast. The browser default for placeholder is light gray (#a9a9a9 in most browsers), which fails on white. Override with CSS: ::placeholder { color: #595959; } or similar that passes AA. Better still, avoid placeholders entirely for important fields; use visible labels above the field and reserve placeholders for example formatting. Floating-label patterns combine the visible label and example clarity.

Does contrast apply to disabled buttons and form fields?

No. WCAG SC 1.4.3 explicitly exempts disabled controls because the muted appearance is itself a visual signal that the control is unavailable. Disabled buttons are typically faded to about 38% opacity and would fail contrast in their disabled state by design. However, the disabled state must still be clearly distinguishable from the enabled state, so do not just remove all visual treatment; use a clear visual difference plus a screen-reader-accessible disabled attribute.

What about contrast for graphical content like charts and icons?

WCAG 1.4.11 Non-text Contrast (added in 2.1) requires 3:1 contrast for UI components (buttons, form borders, focus indicators) and meaningful graphical elements (icons that convey state, chart elements that distinguish data series). The 3:1 threshold is lower than the 4.5:1 for text because graphics generally have larger visible areas. Decorative graphics that do not convey meaning are exempt. Apply 3:1 to every icon that conveys state (open eye for visible, X for delete, checkmark for selected) and every chart segment that needs to be distinguishable.