Skip to content
ColorArchive
Design Systems
Search intent: color scale generator, tints and shades, tailwind color scale, design system colors

How to Build a Tints and Shades Color Scale for Any Brand Color

A complete guide to generating tonal color scales for design systems. Learn the difference between tints, shades, and tones, the WCAG contrast requirements for each step, and how to choose the right scale for your brand.

Design SystemsColor Theory
Key points
Tints add white (raise lightness, reduce saturation). Shades add black (lower lightness). Tones add gray (reduce saturation at fixed lightness). All three preserve the original hue angle.
WCAG AA requires 4.5:1 contrast. Steps 50–200 typically pass with black text; steps 700–950 pass with white text. Steps 300–600 are midrange — designate them as non-text colors in your token system.
Do not force your brand color into step 500. Identify its natural lightness position (400, 500, 600, etc.) and anchor the scale there. The step number is a label, not a constraint.

Tints, shades, and tones: understanding the difference

A tint is created by adding white to a color — in HSL terms, increasing lightness while reducing saturation. A shade is created by adding black — decreasing lightness. A tone is created by adding gray — reducing saturation while keeping lightness roughly constant. In a tonal scale for a design system, tints occupy the light steps (50–400), the base color anchors the mid step (500), and shades fill the dark steps (600–950). Each operation preserves the original hue, which is what makes the scale feel like a single, coherent color family rather than a collection of separate colors.

Contrast requirements across a tonal scale

WCAG 2.1 AA compliance requires 4.5:1 contrast for normal-size text and 3:1 for large text (18pt+ or 14pt bold). Across an 11-step scale, this creates a predictable pattern: steps 50–200 typically pass AA with black text, steps 700–950 typically pass AA with white text, and steps 300–600 fall into the midrange where neither black nor white achieves the full 4.5:1 ratio for normal text. The correct design system response is to designate midrange steps as non-text colors — suitable for borders, backgrounds, and decorative elements — and explicitly forbid their use for body text. Document this in your token specifications.

Building a scale from a brand color

The most common mistake when building a tonal scale is forcing the brand color into step 500 regardless of its natural lightness. A bright electric blue (L≈60%) that belongs at step 400 will look washed-out if stretched to step 500. A deep burgundy (L≈30%) that belongs at step 700 will lose its character if lightened to step 500. The correct approach: (1) Enter the brand color into a tonal scale tool. (2) Identify which step it most closely matches by comparing lightness. (3) Declare that step as the primary action color in your design system — whether it is 400, 500, or 600 — and build the rest of the scale outward. The step number is a label, not a constraint.

Saturation management across the scale

Saturation behavior determines whether a scale reads as unified or disconnected. For vivid hues like electric blue or bright orange, the light steps (50–200) require significant saturation reduction to avoid looking like washed-out pastels rather than true tints. For muted, earthy hues like sage, terracotta, or slate, saturation is already low and should change minimally across the scale to preserve character. As a rule: reduce saturation in tints (steps 50–300) by 30–70% relative to the base, and reduce saturation slightly in deep shades (steps 800–950) by 15–25%. The exact values depend on the base hue's starting saturation.

Exporting a color scale for use in code

A tonal scale should be exported in the format your engineering team uses. CSS custom properties are the most universal: --color-primary-500: #2563EB. Tailwind CSS config allows extending the color palette with a named scale that integrates with all Tailwind utilities. Sass variables work for older preprocessor-based systems. JSON is useful as a format-agnostic source of truth that can be transformed into any target format. Regardless of format, the naming convention should be consistent — {palette-name}-{step} — and the full scale should be included even if only a few steps are currently in active use, so the system can grow without gaps.

Practical next step

Move from the guide into a concrete palette lane

Guides explain the use case. Collections prove the taste. Packs handle the export and implementation layer.

Related guides