Color Shades Generator

About Color Shades Generator

How the Shades Are Generated

The tool converts your input colour to HSL (Hue, Saturation, Lightness), then interpolates lightness values across 11 steps. HSL separates colour into three channels: hue is the base colour on a 0-360 degree wheel, saturation controls intensity from grey (0%) to full colour (100%), and lightness runs from black (0%) through the pure colour (50%) to white (100%). This separation makes it straightforward to create tints (adding white by raising lightness) and shades (adding black by lowering lightness) without shifting the hue.

Pure lightness scaling tends to produce washed-out lights and muddy darks. The algorithm compensates by slightly increasing saturation in the mid-range and decreasing it at the extremes, keeping the palette vibrant across all 11 steps.

Worked example: Start with Tailwind blue-500 (#3b82f6). The hex converts to RGB(59, 130, 246), which in HSL is roughly hsl(217, 91%, 60%). To generate the 50 shade, lightness shifts to about 97% with saturation reduced slightly, producing a near-white blue tint. For the 950 shade, lightness drops to about 10% with lower saturation, producing a deep navy. The 11 intermediate values fill out the scale evenly between those extremes.

Shade	Typical Lightness	Common Use
50	~95-97%	Very light backgrounds, subtle highlights
100	~90-93%	Light backgrounds, hover states on light surfaces
200	~80-85%	Light borders, dividers, disabled backgrounds
300	~65-75%	Secondary accents, tags, badges
400	~55-65%	Placeholder text, secondary icons
500	~45-55%	Primary colour - buttons, links, key UI elements
600	~38-48%	Hover state for primary, slightly darker accent
700	~30-40%	Active state, pressed buttons
800	~22-32%	Dark text on light backgrounds
900	~15-22%	Headings, high-emphasis text
950	~5-12%	Near-black, dark mode backgrounds, highest contrast text

HSL vs OKLCH - Which Colour Space Should You Use?

HSL has been the standard for web colour manipulation for years, but it has a known weakness: perceptual non-uniformity. Two colours at the same HSL lightness can look drastically different to the human eye. Yellow at 50% lightness appears far brighter than blue at 50% lightness, because HSL lightness is a mathematical average of RGB channels rather than a measure of how bright a colour actually looks.

OKLCH is a newer colour space designed by Bjorn Ottosson that fixes this problem. It uses perceptual lightness, meaning equal numerical steps produce equal visual steps regardless of hue. Tailwind CSS v4 switched its entire default palette from RGB to OKLCH for this reason, taking advantage of wider gamut displays to produce more vivid colours.

For most practical shade generation, HSL works well. The differences matter most when building palettes across multiple hues where you need exact visual consistency - for example, ensuring a blue button and a green button look equally bright. For single-hue shade scales like this tool generates, HSL produces clean, usable results. If you need cross-hue consistency, consider converting your generated shades to OKLCH values using the colour converter.

Using Shades in a Design System

A full shade scale gives you everything needed for interactive states, text hierarchy, and surface layering without inventing new colours. Most modern design systems follow a layered token approach: primitive tokens hold the raw colour values (blue-500: #3b82f6), while semantic tokens describe intent (color-primary: blue-500, color-error: red-500). The shade scale provides the primitive layer.

UI Element	Recommended Shade	Why
Page background	50 or white	Lightest possible, provides a clean canvas
Card / section background	50 or 100	Subtle separation from page background
Border / divider	200 or 300	Visible but not distracting
Disabled text	300 or 400	Clearly de-emphasised
Body text	700 or 800	Good contrast on light backgrounds
Heading text	900 or 950	Highest emphasis, strong contrast
Primary button	500 (default), 600 (hover), 700 (active)	Three-step interactive feedback
Primary button text	50 or white	High contrast against the 500 shade
Focus ring	300 or 400	Visible outline without clashing

The three-state button pattern (500 resting, 600 hover, 700 pressed) is standard across frameworks like Material Design 3 and Radix UI. Having all three shades generated from the same base colour keeps the interaction feeling cohesive rather than using arbitrary darker values.

Building Dark Mode Palettes

A shade scale makes dark mode implementation far simpler. The general rule is to invert the scale: surfaces that use shade 50 in light mode switch to 900 or 950 in dark mode, and text that uses 900 in light mode switches to 50 or 100 in dark mode. Borders typically shift from 200 to 700 or 800.

Element	Light Mode Shade	Dark Mode Shade
Page background	50 / white	950 / near-black
Card background	50 or 100	900
Borders	200	700 or 800
Body text	700 or 800	100 or 200
Heading text	900	50
Primary button	500 / 600 / 700	500 / 400 / 300
Muted text	500	400

Notice that the primary button shades shift direction in dark mode - hover goes lighter (400) instead of darker (600), because darker shades would disappear into the dark background. This is a common source of bugs when converting a light-only design to support dark mode.

Tailwind CSS Integration

The shade numbering (50-950) matches Tailwind's convention, so you can drop the generated values directly into your configuration as a custom colour. In Tailwind v4, custom colours are defined using the @theme directive with CSS variables:

Tailwind Class	Shade Used	Example
bg-brand-50	50	Light page background
text-brand-500	500	Primary text accent
border-brand-200	200	Subtle card border
hover:bg-brand-600	600	Darker hover state
ring-brand-300	300	Focus ring colour

The tool also shows which existing Tailwind colour family is closest to your input by comparing RGB distance across 15 colour families (slate, gray, red, orange, yellow, green, blue, indigo, purple, pink, cyan, teal, emerald, sky, and rose). This helps you decide whether a built-in Tailwind colour is close enough or whether you need a custom scale. If the closest match is within a few shades, you might save yourself a custom theme definition entirely.

Accessibility and WCAG Contrast Requirements

When using your shade scale for text, the contrast ratio must meet WCAG 2.2 standards to be accessible. The W3C Web Content Accessibility Guidelines require a minimum contrast ratio of 4.5:1 for normal text at Level AA, and 3:1 for large text (18pt and above, or 14pt bold). Level AAA raises these to 7:1 and 4.5:1 respectively. Non-text UI components like icons and input borders need at least 3:1 contrast against adjacent colours.

Shade	Approximate Contrast on White	WCAG AA (4.5:1)?	Safe for Body Text?
50-200	Below 2:1	No	No - too light for any text
300	~2-3:1	No	No - only for decorative elements
400	~3-4:1	Borderline	Large text only (18pt+)
500	~4-5:1	Often yes	Depends on the hue - check each colour
600+	5:1 and above	Yes	Yes - safe for body text at normal sizes

These are approximations because contrast depends on the specific hue. A yellow-500 will have much lower contrast on white than a blue-500 at the same lightness level. Always verify specific colour pairs with the colour contrast checker rather than relying on shade number alone.

Common Mistakes When Building Colour Scales

Generating shades seems simple, but a few pitfalls trip up even experienced designers:

Using pure lightness without saturation adjustment. Scaling lightness alone from 0% to 100% produces greyish midtones and either neon-bright or muddy extremes. Good shade generators adjust saturation alongside lightness to keep colours looking natural across the full range. This is the difference between a professional-looking palette and one that feels flat.

Ignoring perceptual brightness differences between hues. Yellow is inherently brighter than purple at the same lightness level in HSL. A shade-500 yellow will look much lighter than a shade-500 indigo because HSL lightness is a mathematical average of RGB channels, not a measure of perceived brightness. If your design uses multiple colour families, test them side by side to make sure they feel balanced visually, not just numerically.

Picking too many custom colours. Most design systems work well with one primary colour, one or two neutrals, and three to four functional colours (success, warning, error, info). Generating a full 11-shade scale for each of these keeps the system consistent without ad-hoc colour picks scattered through the codebase. A typical project needs five to seven colour families at most.

Forgetting dark mode from the start. Retrofitting dark mode into a design that only considered light shades is painful. If you generate your shade scales early and map both light and dark tokens from the beginning, switching modes becomes a simple variable swap rather than a full audit of every component.

Not exporting as CSS custom properties. Hardcoding hex values throughout a stylesheet makes updates tedious. Exporting your shade scale as CSS variables (--color-50 through --color-950) means you can change the entire palette by updating one block of declarations. This tool generates that CSS block ready to paste into a :root selector.

For full colour format conversion between HEX, RGB, HSL, and more, use the colour converter. To build multi-colour palettes with complementary, analogous, or triadic harmony, try the colour palette generator. Everything runs in your browser with no data sent to any server.

Sources

• W3C - Web Content Accessibility Guidelines (WCAG) 2.2
• Wikipedia - HSL and HSV colour models
• Tailwind CSS - Customizing Colors
• Evil Martians - OKLCH in CSS: why we moved from RGB and HSL
• Nathan Curtis, EightShapes - Naming Tokens in Design Systems