Color Palette Workflows: Harmony, Extraction, Design Systems, and Accessibility

Choosing a color palette is one of the most consequential decisions in UI design — and one of the most error-prone when done by feel alone. A systematic approach covers three separate stages: selecting harmonious hues from the color wheel, building a full tonal scale for each hue, and verifying every swatch pair for accessibility. The Palette Generator, Palette Extractor, and Tints and Shades tools cover all three stages without sending your data to a server.

Color Harmony Rules

The color wheel encodes relationships between hues as angles. Harmony schemes exploit those angles to create palettes that feel intentional rather than arbitrary.

These relationships are defined in HSL or HSV hue space (0–360°). A complementary pair to hsl(210, 80%, 50%) (blue) is hsl(30, 80%, 50%) (orange) — simply add 180° and wrap around at 360.

When Each Scheme Works

Picking a harmony is less about aesthetics and more about communication intent.

• Complementary — use when one color must stand out against another: a call-to-action button on a page background, a warning badge on a neutral card, a highlighted row in a data table. The tension between opposite hues directs the eye immediately.
• Analogous — use for calm, cohesive interfaces where the goal is continuity: dashboards, document editors, settings panels. Users should focus on content, not the color system.
• Triadic — use for expressive, high-energy contexts: children's applications, gaming interfaces, marketing landing pages. Three equidistant hues at full saturation produce maximum vibrancy; reducing saturation on two of the three restores usability.
• Monochromatic (single hue, varied lightness) — use for data visualization where the quantity axis should be color rather than hue: heat maps, choropleth maps, sparklines. A single hue at steps from 10% to 90% lightness communicates magnitude without introducing categorical meaning.
• Tetradic — use sparingly. Four hues are hard to balance. Assign roles explicitly: primary, accent, semantic positive, semantic negative.

Extracting Colors from Images

When a brand already has visual assets — a product photo, a hero illustration, a logo — the palette should derive from those assets rather than be chosen independently. Two algorithms dominate color extraction.

K-means in LAB Space

K-means clustering partitions pixel colors into k groups by minimizing the distance from each pixel to its cluster center. The key detail is the color space: k-means run in sRGB produces clusters weighted by display values, not by perceived difference. Running the same algorithm in CIE LAB (or OKLAB) space gives perceptually uniform distances, so the clusters reflect colors that actually look distinct to human eyes rather than colors that differ numerically.

In practice, k-means with k = 5 in LAB space reliably identifies the dominant hues in a photograph. Increasing k reveals more nuance; decreasing it produces a simpler summary.

Median Cut

Median cut recursively splits the color space along its longest axis, dividing pixels into buckets and taking the median of each bucket as the representative color. It is computationally cheaper than k-means and produces more evenly distributed samples across the color gamut of the image — useful when you want representation from every color region rather than dominance by the largest one.

Why Extraction Results Differ

Different tools report different "dominant" colors from the same image because they differ on three axes: algorithm (k-means vs median cut vs histogram), color space (sRGB vs LAB), and post-processing (merging near-duplicates, filtering near-grays, filtering near-whites/blacks). An outdoor photo with a large sky and a small subject will return primarily blue from k-means, but median cut may return more colors from the subject because it samples across the full range.

Extraction Workflow

Use the Palette Extractor to pull the dominant colors out of any image file. The tool runs entirely in your browser — no upload, no third-party API.

1. Drop an image (PNG, JPEG, WebP, or SVG) onto the extractor.
2. Choose the number of colors (5 is a good starting point for most photography).
3. Review the swatches. Near-duplicate neutrals — off-whites, grays — are common in photographs and rarely useful as brand colors. Deselect them.
4. Copy the extracted hex values into the Palette Generator to explore harmony variants built around each extracted hue.

One common pitfall: if the image has a large solid background (white studio, gray backdrop), the extractor will identify that background as the dominant color. Either crop it out before extracting, or ignore background swatches manually.

Building Design System Scales

A single brand color is not enough for a design system. You need a tonal scale — a progression from near-white to near-black — so that every component (button, badge, background, border, text) has an appropriate shade to draw from without improvising.

The Tailwind CSS convention labels steps 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 950. Step 500 is the base hue. Steps below 500 are lighter (tints); steps above 500 are darker (shades). A well-constructed scale follows these usage patterns:

OKLCH for Perceptually Uniform Steps

Generating tints and shades in sRGB or HSL produces uneven perceptual steps. Two swatches that are numerically equidistant in HSL lightness may look very different in perceived brightness — particularly in the blue and purple regions of the spectrum. This is because HSL lightness does not correlate linearly with human luminance perception.

OKLCH (oklch(L C H) in CSS) fixes this. The L channel is perceptually uniform: a step from L=0.3 to L=0.4 looks the same size as a step from L=0.6 to L=0.7, regardless of hue. Interpolating your scale in OKLCH produces steps that visually feel evenly spaced.

/* Generating a 9-step scale in OKLCH */
:root {
  --brand-50:  oklch(0.97 0.03 250);
  --brand-100: oklch(0.93 0.06 250);
  --brand-200: oklch(0.87 0.09 250);
  --brand-300: oklch(0.79 0.12 250);
  --brand-400: oklch(0.70 0.15 250);
  --brand-500: oklch(0.60 0.18 250);  /* base hue */
  --brand-600: oklch(0.50 0.17 250);
  --brand-700: oklch(0.40 0.14 250);
  --brand-800: oklch(0.30 0.10 250);
  --brand-900: oklch(0.20 0.06 250);
}

Note that chroma (C) also needs to decrease as lightness approaches 0 or 1 — highly saturated near-blacks and near-whites are not achievable in the sRGB gamut and will be clamped by browsers.

Tints and Shades Workflow

Use the Tints and Shades tool to generate a complete tonal scale from a single hex value. Enter your brand color at step 500, choose the number of steps, and the tool produces hex values for the full range. Export the result as CSS custom properties and paste it directly into your design token file or Tailwind config.

// tailwind.config.js — pasting generated scale
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: {
          50:  '#f0f4ff',
          100: '#dce6fd',
          200: '#b9ccfb',
          300: '#8aabf8',
          400: '#5a87f4',
          500: '#2563eb',  // brand base
          600: '#1d52d0',
          700: '#1641a8',
          800: '#103180',
          900: '#0a2160',
          950: '#060f30',
        },
      },
    },
  },
};

Contrast Constraints

A palette that looks good in a design mockup can still fail in production if the text and background pairings do not meet WCAG contrast requirements. WCAG 2.1 defines two thresholds:

• AA (minimum): 4.5:1 for normal text, 3:1 for large text (18pt regular or 14pt bold) and UI components.
• AAA (enhanced): 7:1 for normal text, 4.5:1 for large text.

For a primary button (brand-500 background, white text), the contrast must be at least 4.5:1. If it is not, shift the background to brand-600 or brand-700. The lighter end of the scale (brand-50, brand-100) is safe as a background for dark text (brand-900) but will fail with white text — never use light tints as button backgrounds with white labels.

Test each swatch pair systematically before finalizing the palette. The Color Picker shows the contrast ratio for any two colors you enter. Related reading: Color Contrast and WCAG.

Color-Blindness Check

Approximately 8% of men and 0.5% of women have some form of color vision deficiency. The two most common types are:

• Protanopia — reduced sensitivity to red wavelengths. Red and green appear similar; red looks very dark.
• Deuteranopia — reduced sensitivity to green wavelengths. The most common form; red and green again appear similar but the lightness relationships differ from protanopia.
• Tritanopia — reduced sensitivity to blue wavelengths. Rare; blue and green, and yellow and red, appear similar.

Simulate each deficiency on your palette before shipping. If your semantic colors — success green and error red, for example — look identical under deuteranopia simulation, add a secondary distinguishing property: icon shape, text label, or lightness difference. Never rely on hue alone to convey meaning.

See Designing for Color Blindness for a full simulation workflow.

Other Tools Worth Knowing

Several external tools complement the DevToys workflow for specific tasks:

• Coolors — fast random palette generation with keyboard-driven locking. Good for exploration when you have no starting color.
• Adobe Color — applies the harmony rules described above with a visual wheel interface. Useful for teaching clients why two colors were chosen.
• Huemint — uses a machine learning model to generate contextual palettes that fit a described use case (e.g., "fintech dashboard", "children's reading app"). Useful when you want an AI starting point rather than a mathematically derived one.

For generating and verifying palettes locally without uploading images or colors to external servers, use the DevToys tools: Palette Generator, Palette Extractor, and Tints and Shades.

Common Pitfalls

• HSL lightness lies. The HSL lightness channel is a geometric average of the RGB channels, not a perceptual measure. Two colors at the same HSL lightness can look dramatically different in brightness — particularly yellow (which appears bright) versus blue (which appears dark) at identical HSL lightness values. Use OKLCH for any lightness-based comparisons.
• Extracted palettes include background colors. Any image with a large uniform background — a white product photo backdrop, a gray stage, a blue sky — will have that background color appear prominently in extraction results. Filter it out before using the swatches as brand colors.
• Trusting algorithmic generators blindly. Both harmony-rule generators and ML-based tools produce mathematically or statistically valid results that may still look wrong in context. A triadic palette at full saturation is mathematically harmonious but visually overwhelming in a business application. Always reduce saturation on two of the three hues, or limit the vibrant hue to accent-only use.
• Skipping contrast verification on the full scale. It is tempting to test only the primary button color and call the palette accessible. Every pairing that appears in the UI — badge text on badge background, link color on page background, input placeholder on input field — needs its own contrast check.

Build your palette systematically with the Palette Generator, extract brand colors from existing assets with the Palette Extractor, generate full tonal scales with Tints and Shades, and verify every pair with the Color Picker — all without sending your data anywhere.