DEV Community: Ali Badshah

Seasonal Color Analysis for Developers: Soft Summer UI vs Deep Winter Dark Mode

Ali Badshah — Sat, 22 Aug 2026 15:05:00 +0000

`#D8C7D8`	`#8FA1B3`	`#E6DDE3`	`#9B8FA3`	`#6D0F2B`	`#004D40`	`#0B3D91`	`#2A1458`

🎨 Palettes in play — Soft Summer Atelier (left) vs Deep Winter Journal (right)

Seasonal color analysis sounds like something that belongs in a fashion magazine, and that is exactly why developers skip it. Underneath the vocabulary, though, it is a two-axis classification system — and it happens to answer the two questions we ask about every UI theme:

Temperature — are the colors warm (yellow-based) or cool (blue-based)?
Contrast + saturation — is the palette loud and high-contrast, or muted and quiet?

Once you sort palettes along those two axes, "pick a theme" becomes "pick a quadrant" — and that is a decision you can make in ten seconds.

🧭 1 · The map

Season	Temperature	Contrast	Feels like	Ships well as
Spring	warm	bright	fresh, playful	marketing, kids apps, onboarding
Summer	cool	soft	calm, hazy	reading apps, wellness, docs
Autumn	warm	muted-rich	grounded, earthy	food, crafts, editorial, commerce
Winter	cool	high	sharp, precise	dashboards, fintech, dev tools

Each season splits again — soft summer, cool summer, true summer, light summer; deep winter, bright winter, dark winter, cool winter — and every sub-season is its own URL:

$ tree seasonal-palettes
season
├── spring/{spring,light,warm,bright,true}-color-palette
├── summer/{summer,soft,cool,light,true}-color-palette
├── autumn/{autumn,soft,deep,dark,warm,true}-color-palette
└── winter/{winter,deep,cool,bright,dark,true}-color-palette

🌫️ 2 · Soft Summer — the low-contrast reading UI

`#D8C7D8`	`#8FA1B3`	`#E6DDE3`	`#9B8FA3`

Soft summer is cool, greyed-down and deliberately low contrast — dusty mauve, slate blue, fog. It is the palette equivalent of a quiet room. Ideal for long-form reading, journaling apps, meditation timers, documentation, anything where the interface should get out of the way.

And it is a trap if you use it naively:

Pair	Ratio	Verdict
`#8FA1B3` on `#E6DDE3`	2.00:1	🚫 unreadable
`#9B8FA3` on `#E6DDE3`	2.31:1	🚫 unreadable
`#D8C7D8` on `#E6DDE3`	1.21:1	🚫 invisible

Every in-palette pair fails. That does not make the palette bad — it means soft summer is a set of surfaces, and you must bring your own ink.

soft-summer.css ⌁ palette for atmosphere, one dark for type

:root {
  /* from the palette — surfaces only */
  --color-page:     #E6DDE3;
  --color-card:     #D8C7D8;
  --color-line:     #9B8FA3;
  --color-muted:    #8FA1B3;

  /* the color you had to add yourself */
  --color-ink:      #241F2B;   /* 12.11:1 on --color-page ✅ AAA */
  --color-ink-soft: #4A4353;   /*  7.13:1                 ✅ AAA */
}

body {
  background: var(--color-page);
  color: var(--color-ink);
  font-size: 1.0625rem;
  line-height: 1.7;
  max-width: 68ch;
}

.card {
  background: var(--color-card);
  border: 1px solid color-mix(in srgb, var(--color-line) 45%, transparent);
  border-radius: 16px;
}

.meta { color: var(--color-ink-soft); }        /* not --color-muted! */
hr    { border: 0; border-top: 1px solid var(--color-line); }

🧪 Lab note — the muted palette colors still do real work: borders, dividers, disabled states, chart fills, hover backgrounds. They just never carry text. Write that rule into the theme file as a comment and code review gets 80% easier.

❄️ 3 · Deep Winter — the dark mode that isn't grey soup

`#6D0F2B`	`#004D40`	`#0B3D91`	`#2A1458`

Deep winter is cool, saturated and high contrast: burgundy, emerald, royal blue, deep purple, black, icy white. Those are jewel tones, and jewel tones are the reason a dark theme can look expensive instead of looking like #333.

The colors are dark enough to be backgrounds and saturated enough to be identities:

Color	vs `#FFFFFF`	vs `#050505`	Natural role
`#6D0F2B`	11.98:1 ✅	1.70:1	destructive / danger surface
`#004D40`	9.83:1 ✅	2.07:1	success surface
`#0B3D91`	10.04:1 ✅	2.03:1	info / primary surface
`#2A1458`	15.68:1 ✅	1.30:1	elevated background

Read that table sideways and the theme designs itself: these four are surfaces on a black canvas, each carrying white text at AAA.

deep-winter.css ⌁ status colors that are also backgrounds

:root[data-theme='deep-winter'] {
  --bg-base:      #050505;
  --bg-raised:    #14101F;
  --bg-elevated:  #2A1458;

  --ink:          #F5F7FA;   /* 18.99:1 on --bg-base ✅ AAA */
  --ink-muted:    #A9B2C3;

  --info:         #0B3D91;
  --success:      #004D40;
  --danger:       #6D0F2B;

  /* icy accents live on top of the jewel surfaces */
  --info-ink:     #DCE9FF;
  --success-ink:  #D6F5EE;
  --danger-ink:   #FFE1E8;
}

.alert {
  border-radius: 12px;
  padding: 0.9rem 1.1rem;
  border-left: 4px solid currentColor;
}
.alert--info    { background: var(--info);    color: var(--info-ink); }
.alert--success { background: var(--success); color: var(--success-ink); }
.alert--danger  { background: var(--danger);  color: var(--danger-ink); }

Compare that to the default dark theme most projects ship:

- --bg-base:    #1e1e1e;   /* warm grey, no identity            */
- --info:       #2196f3;   /* material blue, seen it 10,000 times */
- --success:    #4caf50;
- --danger:     #f44336;
+ --bg-base:    #050505;   /* true black, lets jewels glow       */
+ --info:       #0B3D91;   /* royal blue, 10.04:1 with white     */
+ --success:    #004D40;   /* emerald, 9.83:1                    */
+ --danger:     #6D0F2B;   /* burgundy, 11.98:1                  */

Same semantics, completely different product personality — and the accessibility numbers went up.

🍂 4 · The other two quadrants, briefly

Warm Autumn — Lagoon Warm Autumn

`#FFEAB6`	`#FFEEBA`	`#FFD489`	`#F9BA5D`

Honey, amber, clay. Near-monochrome warmth for food, artisan commerce and editorial. Total internal contrast: 1.45:1 — surfaces only, again. Pair with #3A2A12.

Bright Spring — Spring Beach Wave

`#FFFF79`	`#FFD2DC`	`#56D5CC`	`#FF8D08`

Maximum energy. Great for a launch page, exhausting for a workspace. Use one as the hero background and keep the rest for illustration.

Cool Winter — Cool Winter Harmony

`#003566`	`#0077B6`	`#D0006F`	`#C1121F`

Icy blue structure with a shout. This is the fintech dashboard palette: navy chrome, blue data, magenta for the one number that matters.

🧮 5 · Pick your quadrant with a function

If you would rather derive the season than browse it, the two axes are computable:

warmth = cos (h - 6 0^{\circ}) where h = hue in degrees

const toHsl = (hex) => {
  const [r, g, b] = hex.replace('#', '').match(/\w\w/g).map((h) => parseInt(h, 16) / 255);
  const max = Math.max(r, g, b), min = Math.min(r, g, b), d = max - min;
  const l = (max + min) / 2;
  const s = d === 0 ? 0 : d / (1 - Math.abs(2 * l - 1));
  let h = 0;
  if (d !== 0) {
    if (max === r) h = ((g - b) / d) % 6;
    else if (max === g) h = (b - r) / d + 2;
    else h = (r - g) / d + 4;
  }
  return { h: (h * 60 + 360) % 360, s, l };
};

export function classify(palette) {
  const hsl = palette.map(toHsl);
  const warmth = hsl.reduce((a, c) => a + Math.cos(((c.h - 60) * Math.PI) / 180), 0) / hsl.length;
  const sat    = hsl.reduce((a, c) => a + c.s, 0) / hsl.length;
  const spread = Math.max(...hsl.map((c) => c.l)) - Math.min(...hsl.map((c) => c.l));

  const warm = warmth > 0;
  const loud = sat > 0.5 || spread > 0.55;

  if (warm && loud)   return 'spring · warm + bright';
  if (warm && !loud)  return 'autumn · warm + muted';
  if (!warm && loud)  return 'winter · cool + high contrast';
  return 'summer · cool + soft';
}

classify(['#D8C7D8', '#8FA1B3', '#E6DDE3', '#9B8FA3']); // summer · cool + soft
classify(['#6D0F2B', '#004D40', '#0B3D91', '#2A1458']); // winter · cool + high contrast

🧪 A quick jest test so the classifier keeps its promises

import { classify } from './season.js';

test.each([
  [['#FFEAB6', '#FFEEBA', '#FFD489', '#F9BA5D'], /autumn|spring/],
  [['#003566', '#0077B6', '#D0006F', '#C1121F'], /winter/],
  [['#D8C7D8', '#8FA1B3', '#E6DDE3', '#9B8FA3'], /summer/],
])('classifies %s', (palette, expected) => {
  expect(classify(palette)).toMatch(expected);
});

🎚️ 6 · Ship both seasons in one app

The strongest move is not choosing — it is mapping light mode to a soft season and dark mode to a deep one, keeping the same semantic names.

:root {                         /* soft summer, daylight */
  --page: #E6DDE3;  --card: #D8C7D8;  --ink: #241F2B;  --line: #9B8FA3;
}

@media (prefers-color-scheme: dark) {
  :root {                       /* deep winter, night */
    --page: #050505;  --card: #2A1458;  --ink: #F5F7FA;  --line: #3A2A66;
  }
}

.panel {
  background: var(--card);
  color: var(--ink);
  border: 1px solid var(--line);
}

One component, two seasons, zero conditional logic.

🧾 The checklist

Decide temperature first (warm/cool), contrast second (loud/quiet).
Soft seasons = surfaces. Always add your own ink color.
Deep seasons = surfaces and status colors. Check them against white, not against each other.
Map soft → light mode, deep → dark mode, and keep semantic names identical.
Browse the sub-season pages; the sub-season is the real spec, "summer" alone is too broad.

Ready-made seasonal sets — soft summer, deep winter, warm autumn, bright spring — live on ColorFiind with HEX codes and CSS variables on every page.

Explore palettes by season

Which quadrant is your current project in? Post the four hexes below. 👇

From HEX to Design Tokens: One Palette, Six Formats, Five Minutes

Ali Badshah — Sat, 22 Aug 2026 12:37:00 +0000

`#0F172A`	`#00F5D4`	`#F15BB5`	`#9B5DE5`

🎨 Palette in play — Neon Diner Harmony · #0F172A #00F5D4 #F15BB5 #9B5DE5

Four hex codes is not a theme. A theme is four hex codes that survived a rename, a framework, a dark mode toggle and a designer asking "can we make the accent 10% lighter everywhere?"

This post is the pipeline I run every time I pull a palette from anywhere. Same four colors, six formats, and the important part — the naming step in the middle that makes all the rest boring.

📐 The pipeline

$ palette → raw vars → semantic names → framework config → tokens.json → dark mode
   1 min     10 sec      2 min           1 min             30 sec       auto

HEX	On `#0F172A`	Grade	Job
`#0F172A`	—	—	surface
`#00F5D4`	12.76:1	✅ AAA	primary
`#F15BB5`	5.87:1	✅ AA	accent
`#9B5DE5`	4.33:1	🟡 AA Large	support

1️⃣ Layer one — the raw palette

Write the raw palette down exactly once. Copy it verbatim and do not touch it again. It is your receipt: it says exactly which palette this theme came from.

styles/palette.css ⌁ raw, never referenced by components

/* Palette: midnight, mint, magenta, violet
 */
:root {
  --palette-color-1: #0F172A;
  --palette-color-2: #00F5D4;
  --palette-color-3: #F15BB5;
  --palette-color-4: #9B5DE5;
}

2️⃣ Layer two — the semantic layer

This is where the value is. Raw hexes describe what a color is; semantic tokens describe what it does. Components only ever see layer two, which is why swapping palettes later costs one file instead of forty.

styles/theme.css ⌁ the only layer components import

:root {
  /* surfaces */
  --color-surface:      var(--palette-color-1);
  --color-surface-alt:  #16213E;
  --color-elevated:     #1B2740;

  /* text */
  --color-ink:          #F8FAFC;
  --color-ink-muted:    #94A3B8;

  /* brand */
  --color-primary:      var(--palette-color-2);
  --color-primary-ink:  #04231D;   /* text ON primary */
  --color-accent:       var(--palette-color-3);
  --color-support:      var(--palette-color-4);

  /* state */
  --color-focus:        var(--palette-color-2);
  --color-danger:       #FF4D6D;

  /* elevation + motion, so the theme owns the whole feel */
  --shadow-glow:        0 0 0 1px color-mix(in srgb, var(--color-primary) 40%, transparent),
                        0 8px 30px -12px var(--color-primary);
  --radius:             12px;
}

🧪 Lab note — --color-primary-ink is the token people forget. Every brand color needs a partner that is readable on top of it. #00F5D4 is bright: white text on it is 1.4:1 (invisible), while #04231D on it is 11.88:1. Store the answer once instead of rediscovering it in every button.

3️⃣ Layer three — the component layer

Components consume semantics and nothing else. Notice there is not a single hex below.

components/button.css ⌁ zero hardcoded colors

.btn {
  background: var(--color-primary);
  color: var(--color-primary-ink);
  border: 0;
  border-radius: var(--radius);
  padding: 0.75rem 1.5rem;
  font-weight: 650;
  transition: filter 150ms ease, box-shadow 150ms ease;
}

.btn:hover   { filter: brightness(1.08); box-shadow: var(--shadow-glow); }
.btn:focus-visible {
  outline: 3px solid var(--color-focus);
  outline-offset: 3px;
}

.btn--accent  { background: var(--color-accent);  color: #1A0B12; }
.btn--support { background: var(--color-support); color: #FFFFFF; }
.btn--ghost {
  background: transparent;
  color: var(--color-primary);
  box-shadow: inset 0 0 0 1.5px currentColor;
}

Here is the refactor that usually happens at this point, in the format that makes it obvious:

  .pricing-card__badge {
-   background: #F15BB5;
-   color: #ffffff;
-   border: 1px solid #9B5DE5;
-   border-radius: 12px;
+   background: var(--color-accent);
+   color: #1A0B12;
+   border: 1px solid var(--color-support);
+   border-radius: var(--radius);
  }

Two wins in four lines: the palette became swappable, and the white-on-pink text (3.04:1 — a fail for body copy) became near-black on pink at 6.27:1.

4️⃣ Tailwind, SCSS, and everything else

Same four colors, wearing different clothes.

tailwind.config.js ⌁ semantic names all the way down

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ['./src/**/*.{html,js,jsx,ts,tsx,vue,svelte}'],
  theme: {
    extend: {
      colors: {
        surface: { DEFAULT: '#0F172A', alt: '#16213E', elevated: '#1B2740' },
        primary: { DEFAULT: '#00F5D4', ink: '#04231D' },
        accent:  '#F15BB5',
        support: '#9B5DE5',
      },
      boxShadow: {
        glow: '0 8px 30px -12px #00F5D4',
      },
    },
  },
};

<button class="bg-primary text-primary-ink hover:shadow-glow rounded-xl px-6 py-3 font-semibold">
  Deploy
</button>

🎁 SCSS, Styled Components, CSS-in-JS and Sass maps

// _palette.scss — Neon Diner Harmony
$surface: #0F172A;
$primary: #00F5D4;
$accent:  #F15BB5;
$support: #9B5DE5;

$theme: (
  'surface': $surface,
  'primary': $primary,
  'accent':  $accent,
  'support': $support,
);

@function theme($key) {
  @return map-get($theme, $key);
}

.badge { background: theme('accent'); }

// theme.ts — typed, so a typo is a build error
export const theme = {
  surface: '#0F172A',
  primary: '#00F5D4',
  accent:  '#F15BB5',
  support: '#9B5DE5',
} as const;

export type ThemeColor = keyof typeof theme;

5️⃣ tokens.json — the format that outlives your framework

If design tooling is anywhere near your project, export W3C-style design tokens. Style Dictionary, Figma plugins and Storybook all speak this.

tokens/palette.tokens.json ⌁ the portable version

{
  "$schema": "https://design-tokens.github.io/community-group/format/",
  "palette": {
    "$description": "Neon Diner Harmony",
    "surface": { "$type": "color", "$value": "#0F172A" },
    "primary": { "$type": "color", "$value": "#00F5D4" },
    "accent":  { "$type": "color", "$value": "#F15BB5" },
    "support": { "$type": "color", "$value": "#9B5DE5" }
  }
}

$ npx style-dictionary build
css
  ✔ build/css/variables.css
ios
  ✔ build/ios/StyleDictionaryColor.h
android
  ✔ build/android/colors.xml

6️⃣ Light mode for free

Because components never touch hexes, an entire second theme is one media query. Swap the neon palette for a light one — here Quartz Drift — and keep every semantic name identical.

`#F5F7F9`	`#E3DFF1`	`#E0AED7`	`#994129`

:root {
  color-scheme: dark light;
}

@media (prefers-color-scheme: light) {
  :root {
    --color-surface:     #F5F7F9;
    --color-surface-alt: #E3DFF1;
    --color-ink:         #241B2F;
    --color-ink-muted:   #5B5468;
    --color-primary:     #994129;   /* 6.22:1 on #F5F7F9 ✅ */
    --color-primary-ink: #FFFFFF;
    --color-accent:      #E0AED7;
    --color-support:     #7A5AA8;
  }
}

/* user override beats the OS */
[data-theme='light'] { /* …same block… */ }

// theme-toggle.js
const KEY = 'theme';
const saved = localStorage.getItem(KEY);
if (saved) document.documentElement.dataset.theme = saved;

document.querySelector('#toggle').addEventListener('click', () => {
  const next = document.documentElement.dataset.theme === 'light' ? 'dark' : 'light';
  document.documentElement.dataset.theme = next;
  localStorage.setItem(KEY, next);
});

🚧 Trap — do not reuse the same accent across both modes without re-checking it. #00F5D4 is 12.76:1 on the dark surface and 1.4:1 on white. Same color, opposite verdict. Each mode needs its own contrast pass.

🤖 Automate the boring 90%

Everything above is deterministic, so it can be a script. Feed it a palette, get every format out:

#!/usr/bin/env node
// palette-to-tokens.mjs — node palette-to-tokens.mjs 0F172A 00F5D4 F15BB5 9B5DE5
import { writeFileSync } from 'node:fs';

const NAMES = ['surface', 'primary', 'accent', 'support'];
const colors = process.argv.slice(2).map((c) => '#' + c.replace('#', '').toUpperCase());
const entries = NAMES.map((n, i) => [n, colors[i]]).filter(([, v]) => v);

const css = `:root {\n${entries.map(([n, v]) => `  --color-${n}: ${v};`).join('\n')}\n}\n`;
const tokens = Object.fromEntries(entries.map(([n, v]) => [n, { $type: 'color', $value: v }]));
const tw = `module.exports = { theme: { extend: { colors: ${JSON.stringify(
  Object.fromEntries(entries), null, 2)} } } };\n`;

writeFileSync('theme.css', css);
writeFileSync('tokens.json', JSON.stringify({ palette: tokens }, null, 2));
writeFileSync('tailwind.colors.js', tw);
console.log('✔ theme.css  ✔ tokens.json  ✔ tailwind.colors.js');

$ node palette-to-tokens.mjs 0F172A 00F5D4 F15BB5 9B5DE5
✔ theme.css  ✔ tokens.json  ✔ tailwind.colors.js

🧾 The checklist

Write the raw palette into palette.css once. Keep the source link in a comment.
Never let a component import layer one.
Every brand color gets an -ink partner that is readable on top of it.
Export tokens.json the moment a designer is involved.
Re-run contrast per mode, not per color.
Script the conversion — you will do it again next project.

Need a palette to run through the pipeline? ColorFiind lists 34,000+ of them with copy-ready HEX codes and a :root block on every page.

Pick a palette, run the pipeline

Next up: seasonal palettes as a theming system — why soft summer makes a beautiful reading app and deep winter makes the best dark mode you have shipped.

How to Pick a Color Palette That Survives Contact With Production

Ali Badshah — Fri, 21 Aug 2026 14:59:00 +0000

`#3C0D4F`	`#F22C33`	`#C6EEA0`	`#1681DF`

🎨 Palette in play — Mango Garden Moment · #3C0D4F #F22C33 #C6EEA0 #1681DF

Picking colors is the part of a side project where an evening quietly disappears. You open a generator, spin the wheel forty times, save three screenshots, and end up shipping the same slate-and-indigo you always ship.

The problem is not taste. It is that a palette is chosen as a picture and used as a system. Four squares side by side always look balanced. The same four colors, applied to a heading, a body paragraph, a disabled button and a focus ring, very often do not.

Here is the process I use to go from "ooh, that one" to a theme that survives code review.

🧩 1 · Read the structure before the colors

Ignore whether you like it for a second and ask: what shape is this palette? Almost every four-color set falls into one of four structures, and the structure tells you what it can be used for.

Structure	Ships well as	Watch out for
Ramp — one hue, four lightnesses	a whole dashboard: bg, borders, muted text, text	no accent — you must add one
Base + signals — one dark, three brights	dark mode with status colours	brights are unreadable on white
Lights + anchor — three pales, one deep	light UI with one strong CTA	only one usable text colour
Near-monochrome — four neighbours	backgrounds, illustration, packaging	no text can live here

That last row is the classic trap. The lightest and darkest of those four honeys are 1.45:1 apart. It is gorgeous, and it is a set of surfaces — bring your own ink or nobody can read your app.

🔬 2 · Test the pairs you will actually ship

A palette is not four colors; it is up to twelve pairings, and only a handful of them matter. Write down the pairs your UI really uses before you write any CSS:

body text on page background
heading on page background
button label on button fill
link on card background
border/icon on its surface

Then measure them. The formula is small enough to keep in the project:

const luminance = (hex) => {
  const [r, g, b] = hex.replace('#', '').match(/\w\w/g).map((h) => {
    const c = parseInt(h, 16) / 255;
    return c <= 0.03928 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4;
  });
  return 0.2126 * r + 0.7152 * g + 0.0722 * b;
};

export const contrast = (a, b) => {
  const [x, y] = [luminance(a), luminance(b)].sort((m, n) => n - m);
  return +((x + 0.05) / (y + 0.05)).toFixed(2);
};

contrast('#3C0D4F', '#C6EEA0'); // 11.84  → AAA, ship it
contrast('#F22C33', '#FFFFFF'); // 4.05   → large or bold text only
contrast('#C6EEA0', '#FFFFFF'); // 1.30   → decorative surface, never text

The thresholds that survive code review:

Ratio	Meaning
4.5:1	body text — non-negotiable
3:1	24px+ text, 19px+ bold, plus borders, icons and focus rings
below 3:1	decoration only: backgrounds, dividers, illustrations, gradients

Run this on the example palette and it grades itself:

HEX	vs `#FFFFFF`	Verdict
`#3C0D4F`	15.41:1	✅ text, headings, ink
`#F22C33`	4.05:1	🟡 buttons and big type
`#C6EEA0`	1.30:1	🚫 surface only
`#1681DF`	4.01:1	🟡 links at 18px+

Nothing here is "bad". The table just tells you which color is allowed to be a paragraph and which one is allowed to be a background — a decision you would otherwise make by accident.

🏷️ 3 · Name the colors after their job

This is the step that separates a palette from a theme. Numbered variables are fine for copying and terrible for maintaining:

  :root {
-   --palette-color-1: #3C0D4F;
-   --palette-color-2: #F22C33;
-   --palette-color-3: #C6EEA0;
-   --palette-color-4: #1681DF;
+   --color-ink:      #3C0D4F;  /* headings, body text        */
+   --color-primary:  #F22C33;  /* buttons, active states     */
+   --color-surface:  #C6EEA0;  /* cards, highlight sections  */
+   --color-link:     #1681DF;  /* links, info, focus rings   */
+   --color-page:     #FFFFFF;
  }

Now components consume intentions, never hexes:

.card {
  background: var(--color-surface);
  color: var(--color-ink);
  border: 2px solid var(--color-ink);
  border-radius: 14px;
  padding: 1.5rem;
}

.card__cta {
  background: var(--color-primary);
  color: #fff;
  border-radius: 999px;
  padding: 0.7rem 1.4rem;
}

.card a {
  color: var(--color-link);
  text-underline-offset: 3px;
}

#3C0D4F on #C6EEA0 is 11.84:1, so that card is readable before you even open a checker. And when someone inevitably says "can we try a different palette?", it is one file, not forty components.

🧰 The same four colors as Tailwind config and design tokens

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        ink:     '#3C0D4F',
        primary: '#F22C33',
        surface: '#C6EEA0',
        link:    '#1681DF',
      },
    },
  },
};

{
  "palette": {
    "ink":     { "$type": "color", "$value": "#3C0D4F" },
    "primary": { "$type": "color", "$value": "#F22C33" },
    "surface": { "$type": "color", "$value": "#C6EEA0" },
    "link":    { "$type": "color", "$value": "#1681DF" }
  }
}

🧠 4 · Four strategies for actually choosing

Start from the mood. Decide the adjective first — calm, expensive, playful, technical — and search for that word rather than for colors. It is much easier to reject a palette that does not feel "calm" than to compare two blues.

Start from the temperature. Warm (yellow-based) palettes read friendly, human, editorial. Cool (blue-based) palettes read precise, clinical, trustworthy. Getting this wrong is why some fintech dashboards feel like a smoothie brand.

Start from a palette you like and walk sideways. Found something close but the contrast is wrong? Nudge one color's lightness by 15% and re-measure instead of starting over. "Same feeling, better legibility" is nearly always two tweaks away.

Start from what your UI actually needs. Count the roles before you count the colors:

$ what does this UI need?
  1 page background
  1 card/surface
  1 ink (text)          ← must clear 4.5:1 on both of the above
  1 primary action
  1 link colour
  3 status colours      ← success / warning / danger
= 8 slots, and your palette gave you 4

That is the honest math. A four-color palette is a starting point — you will derive the rest by tinting, shading and mixing:

:root {
  --color-primary: #F22C33;
  /* derived, not invented */
  --color-primary-hover:   color-mix(in srgb, var(--color-primary) 85%, black);
  --color-primary-subtle:  color-mix(in srgb, var(--color-primary) 12%, white);
  --color-primary-border:  color-mix(in srgb, var(--color-primary) 40%, transparent);
}

🧪 5 · Three quick sanity checks before you commit

Squint test. Blur your eyes at the mockup. If everything mushes into one grey blob, your palette has no contrast hierarchy — a common outcome of very pretty, very muted palettes.

Greyscale test. Screenshot the UI and desaturate it. Buttons should still look like buttons. If two states are identical in greyscale, you are encoding meaning in hue alone, which fails for colorblind users.

One-color-removed test. Delete the accent and look again. If the interface collapses into unusable, you are leaning on decoration to do structural work.

$ checklist
  [ ] body text ≥ 4.5:1 on every surface it appears on
  [ ] focus ring visible on light AND dark backgrounds
  [ ] status colours distinguishable in greyscale
  [ ] one text colour that works on the two most common surfaces
  [ ] hover/active states derived, not hand-picked

🧾 The short version

Identify the structure — ramp, base+signals, lights+anchor, or near-monochrome.
List the pairs your UI ships, and measure only those.
Rename --palette-color-3 into --color-surface; components never see hexes.
Expect a four-color palette to fill about half your slots; derive the rest with color-mix().
Squint, desaturate, and remove the accent before you call it done.

Do that and colour stops being the thing that eats an evening — it becomes four lines in a token file that you can swap in a minute.

If you want a shortcut to step one, ColorFiind is a browsable library of 34,000+ named palettes — every one has its HEX codes, a ready-made :root block and a downloadable swatch image, sorted by category and by season.

Browse 34,000+ colour palettes

What's the palette you're using right now? Drop the four hexes in the comments and I'll tell you which pair is quietly failing. 👇

How Image Compression Quietly Breaks Colour Accessibility

Ali Badshah — Fri, 21 Aug 2026 12:30:00 +0000

`#7C1E3A`	`#FFFFFF`	`#176457`	`#452F73`

🎨 Palette in play — Deep Winter Reef Couture · #7C1E3A #FFFFFF #176457 #452F73

Accessibility audits check contrast against the values in your design file. Users experience contrast against the pixels their browser actually decoded. Between those two things sits an encoder that was asked to make the file smaller, and it does that by changing colours.

Most of the time the change is too small to matter. In three specific situations it is enough to push a passing combination into failure — and those situations are common.

📊 The starting point: values that pass comfortably

This palette is deliberately high-contrast, which is exactly what you want for text over imagery:

Text	Background	Ratio	Grade
`#FFFFFF`	`#7C1E3A`	9.98:1	✅ AAA
`#FFFFFF`	`#176457`	7.01:1	✅ AAA
`#FFFFFF`	`#452F73`	11.01:1	✅ AAA

Plenty of headroom. Now put that white text inside a JPEG instead of in HTML, and watch what compression does to it.

🔨 The three ways compression eats contrast

1 · Ringing around text

JPEG and other DCT-based codecs work in 8×8 blocks. A hard edge — white letterform against a dark background — produces high-frequency information that quantisation can't represent exactly, so the decoder reconstructs it with overshoot: faint dark halos inside the light stroke and light halos outside it.

The consequence for accessibility: the effective colour of a thin white stroke is no longer #FFFFFF. Sample the middle of a 2px stroke in a heavily compressed JPEG and you may find #E4E0E2 — which drops white-on-burgundy from 9.98:1 to 7.63:1. Still fine here. Start from a combination at 4.6:1 and the same effect puts you under the line.

2 · Chroma subsampling shifting the colour, not the brightness

At 4:2:0, colour is stored at quarter resolution. Around coloured text this produces fringing — and if your foreground and background differ mainly in hue rather than lightness, subsampling attacks exactly the channel carrying the distinction.

This is the strongest argument for a rule you already know: contrast should come from lightness, not hue. A design that satisfies WCAG through a big lightness gap is robust to compression. One that scrapes past on a saturated-hue difference is not.

3 · Banding in gradients behind text

A hero with a subtle dark gradient behind white text can band after encoding. Each band is a slightly different background value, so the contrast ratio varies across the headline — and the audit, which sampled one point, never saw it.

🛡️ The fix that solves all three at once

Don't put text inside the image.

<!-- ❌ text baked into the JPEG: contrast depends on the encoder -->
<img src="hero-with-headline.jpg" alt="Winter collection — now available">

<!-- ✅ text in HTML over the image: contrast is exact, selectable, translatable -->
<figure class="hero">
  <img src="hero.avif" alt="" width="1600" height="900">
  <figcaption class="hero__text">Winter collection — now available</figcaption>
</figure>

.hero { position: relative; isolation: isolate; }

.hero img { display: block; inline-size: 100%; block-size: auto; }

.hero__text {
  position: absolute;
  inset-block-end: 0;
  padding: 2rem;
  color: #FFFFFF;
  font-size: clamp(1.5rem, 4vw, 3rem);
  font-weight: 650;
  /* a scrim guarantees the ratio regardless of what the photo does */
  background: linear-gradient(to top, rgb(124 30 58 / 0.92), rgb(124 30 58 / 0));
}

The scrim is the important part: it pins the effective background to a value you chose — here #7C1E3A at 92%, giving white text a computable ratio — instead of whatever the photograph happens to contain after compression.

Benefits beyond contrast: the text is selectable, translatable, searchable, resizable and readable by a screen reader without duplicating it in alt.

🎛️ When the text really must be in the image

Social cards, email headers, some ad formats. Then:

$ # 1 · lossless or near-lossless for anything with text
  magick card.png -define png:compression-level=9 card-out.png
  magick card.png -quality 95 -sampling-factor 4:4:4 card-out.jpg

$ # 2 · never lossy WebP for text (it is always 4:2:0)
  cwebp -lossless card.png -o card.webp

$ # 3 · give the text more headroom than the audit requires
  design at ≥ 7:1 so a compression loss of ~1.5 points still clears 4.5:1

$ # 4 · check the compressed file, not the source

That fourth line is the whole discipline. Audit the artefact you ship.

🧪 Measuring contrast on the file you actually serve

// contrast-after-encode.mjs — sample the real pixels of the delivered image
import sharp from 'sharp';

const luminance = ([r, g, b]) => {
  const f = (c) => {
    const s = c / 255;
    return s <= 0.03928 ? s / 12.92 : ((s + 0.055) / 1.055) ** 2.4;
  };
  return 0.2126 * f(r) + 0.7152 * f(g) + 0.0722 * f(b);
};

const ratio = (a, b) => {
  const [hi, lo] = [luminance(a), luminance(b)].sort((x, y) => y - x);
  return +((hi + 0.05) / (lo + 0.05)).toFixed(2);
};

// average a small patch so a single ringing pixel doesn't skew the result
async function patch(file, left, top, size = 6) {
  const { data } = await sharp(file)
    .extract({ left, top, width: size, height: size })
    .raw().toBuffer({ resolveWithObject: true });
  const px = [0, 1, 2].map((c) => {
    let sum = 0;
    for (let i = c; i < data.length; i += 3) sum += data[i];
    return Math.round(sum / (data.length / 3));
  });
  return px;
}

const fg = await patch('dist/card.jpg', 120, 300);   // inside a letter stroke
const bg = await patch('dist/card.jpg', 60, 300);    // background beside it

console.log('after encoding:', ratio(fg, bg));       // the number that matters

Wire that into CI for your social-card generator and a quality-setting change can never silently break a contrast requirement.

♿ The rest of the accessibility angle

Compression interacts with more than contrast:

Colour-only meaning gets worse. If a chart image distinguishes series by hue and 4:2:0 smears those hues together, the encoding has amplified an existing accessibility failure. Redundant encoding — shape, pattern, direct labels — protects against both.
Banding is a comfort issue. Visible banding in large flat areas is unpleasant for people with light sensitivity or migraine triggers. Noise-dithering a gradient is an accessibility improvement, not just a cosmetic one.
Alt text stops being optional when text lives inside an image. If the headline is in the JPEG and the alt is empty, that headline does not exist for a screen-reader user.
Zoom. Baked-in text pixelates at 200% zoom; HTML text reflows. WCAG asks for the latter.

🧾 The checklist

Contrast must come from a lightness difference — that's the part compression preserves best.
Keep text in HTML over images, with a scrim that fixes the effective background.
If text must be baked in: lossless, or JPEG q95 at 4:4:4. Never lossy WebP.
Design to ≥ 7:1 for text over imagery so encoding losses stay clear of the limit.
Measure contrast on the delivered file, averaged over a patch.
Dither gradients to avoid banding — it's a comfort issue, not just a visual one.
Never rely on hue alone; compression degrades hue distinctions first.

High-contrast palettes make all of this easier, because they start with headroom to lose — the deep-winter style sets on ColorFiind are built around exactly that kind of lightness separation.

Browse high-contrast palettes

Have you ever measured contrast on the compressed file rather than the design? The gap surprises most people. 👇

Color-Gamut Media Queries: Better Product Colour for P3 Displays

Ali Badshah — Thu, 20 Aug 2026 14:30:00 +0000

`#BDE0FE`	`#CDB4DB`	`#FFC8DD`	`#A8DADC`

🎨 Palette in play — Summer Gallery · #BDE0FE #CDB4DB #FFC8DD #A8DADC

"The blouse looked mint online and arrived sage."

Colour is one of the top drivers of returns in apparel and home goods, and a chunk of it is not photography — it's the last few centimetres of the pipeline, where a colour the studio measured carefully gets squeezed into whatever box the shopper's screen provides.

@media (color-gamut) is the CSS tool for that last stretch. It's a small feature with one genuinely confusing behaviour, so let's do it properly.

🧾 The syntax, and the part that confuses everyone

@media (color-gamut: srgb)    { /* ~every colour display in existence */ }
@media (color-gamut: p3)      { /* Display-P3 capable or wider */ }
@media (color-gamut: rec2020) { /* Rec. 2020 capable or wider */ }

The values are cumulative, not exclusive. A P3 display matches srgb and p3. A Rec. 2020 display matches all three. There is no "sRGB only" query.

That has one practical consequence, and it's the bug I see most:

- /* WRONG — the srgb block wins on a P3 display because it comes last */
- @media (color-gamut: p3)   { .swatch { background: color(display-p3 0.4 0.85 0.78); } }
- @media (color-gamut: srgb) { .swatch { background: #A8DADC; } }

+ /* RIGHT — narrow first, wide last, let the cascade upgrade */
+ .swatch { background: #A8DADC; }
+ @media (color-gamut: p3)   { .swatch { background: color(display-p3 0.4 0.85 0.78); } }
+ @media (color-gamut: rec2020) { .swatch { background: color(rec2020 0.38 0.86 0.79); } }

Order narrow → wide. Same rule as min-width breakpoints.

You rarely need (color-gamut: srgb) at all — a plain declaration outside any query is the sRGB case, and it also covers browsers that don't understand the feature.

🛍️ Why an e-commerce team should care

The colours that suffer most in sRGB are exactly the ones product teams argue about: saturated teals, corals, emeralds and true reds. Here's the palette above converted precisely to P3 — these are the coordinates that reproduce the same colour, before you push anything:

Product swatch	sRGB	Display-P3 coordinates
Powder	`#BDE0FE`	`color(display-p3 0.7680 0.8743 0.9844)`
Lilac	`#CDB4DB`	`color(display-p3 0.7877 0.7094 0.8479)`
Blush	`#FFC8DD`	`color(display-p3 0.9663 0.7927 0.8635)`
Mint	`#A8DADC`	`color(display-p3 0.6990 0.8493 0.8591)`

For pastels the gain is modest. Do the same exercise with a saturated coral or emerald and the P3 version is visibly closer to the physical sample — which is the entire business case.

Where it pays in a store:

Swatch chips next to the photo. If the chip is CSS and the photo is a P3 image, they should live in the same space or the mismatch reads as a defect.
"Colour: Sage" filters. Ten green variants need to stay distinguishable; extra gamut buys separation.
Brand-critical packaging shots. The hero colour is the product.

Where it doesn't: price, body copy, chrome, empty states. Don't spend review time there.

🎯 The pattern for a product swatch component

swatches.css ⌁ data attributes + one enhancement block

.swatch {
  inline-size: 2.25rem;
  aspect-ratio: 1;
  border-radius: 50%;
  border: 1px solid rgb(0 0 0 / 0.12);
  background: var(--swatch);
}

[data-colour='powder'] { --swatch: #BDE0FE; }
[data-colour='lilac']  { --swatch: #CDB4DB; }
[data-colour='blush']  { --swatch: #FFC8DD; }
[data-colour='mint']   { --swatch: #A8DADC; }

@media (color-gamut: p3) {
  [data-colour='powder'] { --swatch: color(display-p3 0.7680 0.8743 0.9844); }
  [data-colour='lilac']  { --swatch: color(display-p3 0.7877 0.7094 0.8479); }
  [data-colour='blush']  { --swatch: color(display-p3 0.9663 0.7927 0.8635); }
  [data-colour='mint']   { --swatch: color(display-p3 0.6990 0.8493 0.8591); }
}

.swatch[aria-pressed='true'] {
  outline: 2px solid CanvasText;
  outline-offset: 3px;
}

Two blocks, no per-component duplication, and the selected state uses an outline rather than a colour change — because colour alone must never be the only signal, gamut or no gamut.

🔀 Combining it with everything else

Media features compose, and this is where the pattern earns its keep:

/* wide gamut AND dark mode */
@media (color-gamut: p3) and (prefers-color-scheme: dark) {
  :root { --accent: color(display-p3 0.45 0.88 0.85); }
}

/* respect the user who wants less intensity */
@media (color-gamut: p3) and (prefers-contrast: less) {
  :root { --accent: #A8DADC; }          /* fall back to the calmer sRGB value */
}

/* HDR-capable screens, a separate question from gamut */
@media (dynamic-range: high) {
  .hero { background-image: image-set('hero-hdr.avif' type('image/avif')); }
}

dynamic-range is about brightness range; color-gamut is about how many hues. A screen can be one without the other.

🧑‍💻 Reading it from JavaScript

Useful for analytics — "what share of my traffic can even see the enhancement?" — and for canvas work:

const p3 = window.matchMedia('(color-gamut: p3)');

analytics.track('display_gamut', {
  gamut: p3.matches ? 'p3' : 'srgb',
  hdr: matchMedia('(dynamic-range: high)').matches,
});

// canvas has to opt in explicitly; it clamps to sRGB otherwise
const ctx = canvas.getContext('2d', {
  colorSpace: p3.matches ? 'display-p3' : 'srgb',
});

// gamut can change when a laptop is plugged into an external monitor
p3.addEventListener('change', (e) => rerenderSwatches(e.matches));

That last listener matters more than it sounds. Drag a browser window from a MacBook screen to a cheap external monitor and the match result flips mid-session.

📊 Measuring whether it moved the needle

// tag the gamut on colour-related events so returns data can be sliced by it
const gamut = matchMedia('(color-gamut: p3)').matches ? 'p3' : 'srgb';

analytics.track('variant_selected', { sku, colour: 'mint', gamut });
analytics.track('return_initiated', { sku, reason: 'colour_mismatch', gamut });

If colour-related returns are meaningfully lower on P3 sessions after you ship the enhancement, you have your answer — and a number to take to whoever funds the work.

🚧 Four traps

1 · The cascade order bug. Covered above; it silently disables your enhancement.

2 · Assuming P3 means "accurate". A wide-gamut panel that is uncalibrated is wide and wrong. Enhancement improves the ceiling, not the floor.

3 · Photos and CSS drifting apart. Product images are usually tagged sRGB. If your CSS chips jump to P3 and the photo doesn't, the chip stops matching the garment.

4 · Reviewing only on Apple hardware. Your design team's screens are the least representative sample of your customers' screens.

🧾 The checklist

Plain declaration = sRGB. Add p3, then rec2020, in that order.
Never use (color-gamut: srgb) to undo an enhancement — it matches P3 screens too.
Convert exactly first; push chroma only if the product genuinely needs it.
Keep CSS swatches and product photography in the same colour space.
Selection state uses shape or outline, never colour alone.
Listen for change — the gamut can flip when a monitor is plugged in.
Tag analytics with the gamut so you can prove the impact.

Getting the sRGB baseline right is still the biggest win, and starting from a palette that's already balanced saves the argument — ColorFiind publishes each set with its HEX codes ready to convert.

Browse palettes for your product swatches

Do you know what share of your traffic is on a P3 display? It's a five-line analytics change to find out. 👇

The Swatch Deck — a reusable DEV.to theme kit for color posts

Ali Badshah — Thu, 20 Aug 2026 07:11:05 +0000

DEV.to strips <style> tags and inline style="" attributes, so you cannot paint a div pink and call it a day. What you can do is let images carry the color and let fenced code blocks carry the texture. Two rules make it work: images are block-level on DEV, so anything that must sit side by side goes in a table row; and a divider is a single wide bar, not four small ones.

🧱 The eight blocks

#	Block	What it does	Renders on DEV?
1	Cover band	1000×420 PNG, palette + title	✅
2	Palette band	one-row table, one colour per cell	✅
3	Color rule	one wide 1000×10 bar instead of `---`	✅
4	Swatch table	color + HEX + RGB + HSL + contrast	✅
5	Code tab	filename line above a fenced block	✅
6	Diff block	red/green "before → after"	✅
7	Terminal block	a `console` fence for a shell look	✅
8	Collapsible	the details liquid tag for long code	✅
—	`<style>`, inline style attributes, `<script>`	sanitized away	🚫

1 · Palette band — use a table row, not a line of images

This is the mistake worth learning from. DEV renders every article image as a block element, so four
images on one line do not butt together into a bar — they stack vertically down the page.

- ![a](url)![b](url)![c](url)![d](url)      ← stacks vertically on DEV
+ | `#0F172A` | `#00F5D4` | `#F15BB5` | `#9B5DE5` |
+ | :--: | :--: | :--: | :--: |
+ | ![a](url) | ![b](url) | ![c](url) | ![d](url) |

Table cells are the reliable way to force horizontal layout, and you get the hex codes as a header row
for free:

`#0F172A`	`#00F5D4`	`#F15BB5`	`#9B5DE5`

The URL shape is placehold.co/{W}x{H}/{background}/{textColor}.png. Passing the same hex twice hides
the auto-generated size label, so you get a clean solid block. dummyimage.com/120x56/0f172a/0f172a.png
is a drop-in fallback if placehold.co is ever down.

Keep swatches at 120×56 or smaller inside tables — four columns of 210px overflow the article width
on mobile.

🚧 Trap — the same rule applies inside a cell. Four images in one cell stack too. One colour per
cell, always.

2 · Color rule — one wide bar

A divider wants to be a single image, for exactly the same reason:

![Section divider bar in vivid teal](https://placehold.co/1000x10/00F5D4/00F5D4.png)

It scales down to any screen width, and it beats a grey --- for keeping the article's palette present.

3 · Swatch table

HEX	RGB	HSL	On `#0F172A`	Role
`#0F172A`	`15, 23, 42`	`222° 47% 11%`	—	Base
`#00F5D4`	`0, 245, 212`	`172° 100% 48%`	12.76:1 ✅	Primary
`#F15BB5`	`241, 91, 181`	`324° 84% 65%`	5.87:1 ✅	Accent
`#9B5DE5`	`155, 93, 229`	`267° 72% 63%`	4.33:1 🟡	Support

4 · Code tabs — five looks for five jobs

Give each block a tab line right above it. The bold monospace filename plus an em-dash caption reads like an editor tab and visually separates one code look from the next.

tokens.css ⌁ the source of truth

:root {
  --color-surface: #0F172A;
  --color-primary: #00F5D4;
}

tailwind.config.js ⌁ the framework mirror

module.exports = {
  theme: { extend: { colors: { palette: { surface: '#0F172A' } } } },
};

patch ⌁ before → after, in red and green

- background: #1e1e1e;
- color: #cccccc;
+ background: var(--color-surface);
+ color: var(--color-primary);

terminal ⌁ no syntax highlighting, all vibe

$ npx palette-tokens 0F172A 00F5D4 F15BB5 9B5DE5
✔ wrote tokens.css   (4 custom properties)
✔ wrote tokens.json  (4 design tokens)

data ⌁ machine-readable

{
  // one palette, four tokens
  "surface": "#0F172A",
  "primary": "#00F5D4"
}

5 · Liquid tags worth using

💡 Click to expand a collapsible

Long snippets, alternate framework versions and "the boring full config" belong in here so the article keeps its rhythm.

$surface: #0F172A;
$primary: #00F5D4;

{% details Summary text %} hidden content {% enddetails %}

{% embed https://codepen.io/your/pen %}
{% katex inline %} L = 0.2126R + 0.7152G + 0.0722B {% endkatex %}

6 · Front matter template

---
title: "Your title — max ~60 chars for the card"
published: false
description: "One sentence, 120-160 chars, shows up in the feed and in OG cards."
tags: css, webdev, design, beginners
canonical_url: https://your-site.com/original-post
series: "Color for Developers"
---

🧪 Lab note — tags is a maximum of four, comma separated, no #. cover_image looks best at exactly 1000×420. Keep published: false until the preview looks right, then flip it.

7 · Generate all of it

Every band, table and token block in this series came out of one script:

$ python3 tools/palette_kit.py swatches \
    --name "Neon Diner Harmony" --slug neon-diner-harmony \
    --colors 0F172A 00F5D4 F15BB5 9B5DE5

The palettes used in these examples come from ColorFiind — 34,000+ named palettes with HEX codes, CSS variables and downloadable swatch images on every page.

Browse colour palettes

How to Build a Color System for Your Design System

Ali Badshah — Wed, 19 Aug 2026 14:39:00 +0000

A design system usually starts with components.

Buttons. Inputs. Cards. Navigation. Modals.

But before those components become reusable, there is something underneath almost all of them that needs to be consistent: color.

If every component uses slightly different shades of the same color, the interface starts feeling inconsistent very quickly.

You might have five different grays for borders, three different blues for buttons, and several versions of the same green scattered across your CSS.

It works at first.

Then the project grows.

That's when a proper color system starts becoming extremely useful.

In this article, I'll walk through a practical way to turn a handful of colors into a reusable system that developers and designers can actually work with.

Start With a Small Color Foundation

You don't need 50 colors to create a good design system.

In fact, starting with too many colors can make things harder.

I usually begin with a small foundation:

Primary
Secondary
Neutral
Success
Warning
Error

For example, let's say the main brand color is:

#117A6A
Primary

From this one color, we can create a useful range of shades.

:root {
  --primary-50:  #F1FAF8;
  --primary-100: #DFF3EF;
  --primary-200: #BDE5DE;
  --primary-300: #8CCDC3;
  --primary-400: #5BB5A7;
  --primary-500: #117A6A;
  --primary-600: #0F6E60;
  --primary-700: #0B5B50;
  --primary-800: #08483F;
  --primary-900: #063C35;
}

Now the design system has a predictable range instead of one isolated color.

Why Color Scales Are Better Than Random Shades

Imagine a developer needs a slightly darker version of the primary button.

Without a color system, they might choose:

background: #0C665A;

Another developer might choose:

background: #0A6156;

A designer might later choose:

background: #0E6B5F;

All three may look almost identical.

But now the project has three different colors doing roughly the same job.

That's how color systems slowly become messy.

With a predefined scale, everyone knows where to look:

Primary 500 → Default
Primary 600 → Hover
Primary 700 → Active
Primary 300 → Subtle accent
Primary 100 → Light background
Primary 50  → Very light surface

The exact mapping can change depending on the project, but the principle stays the same.

Give your colors predictable jobs.

Neutrals Are Part of the System Too

When people talk about design systems, they often focus on brand colors.

But neutrals can actually be used much more frequently.

Think about a normal dashboard.

You might need colors for:

Page background
Cards
Borders
Dividers
Primary text
Secondary text
Disabled text
Input backgrounds
Hover states

A small neutral scale can handle most of this.

:root {
  --neutral-50:  #F8FAF9;
  --neutral-100: #EEF3F1;
  --neutral-200: #DDE5E2;
  --neutral-300: #C6D0CD;
  --neutral-400: #9AA7A3;
  --neutral-500: #7B8985;
  --neutral-600: #66736F;
  --neutral-700: #4C5855;
  --neutral-800: #303B38;
  --neutral-900: #17201E;
}

Now instead of creating a new gray whenever you need one, you can choose from an established scale.

A simple neutral system

Token	Example	Typical use
`neutral-50`	`#F8FAF9`	Page background
`neutral-100`	`#EEF3F1`	Subtle surfaces
`neutral-200`	`#DDE5E2`	Borders
`neutral-500`	`#7B8985`	Secondary UI
`neutral-600`	`#66736F`	Muted text
`neutral-900`	`#17201E`	Main text

The advantage is consistency.

A border on one page can use the same token as a border somewhere else.

Then Add Semantic Colors

Brand colors and neutral colors aren't enough.

Most products also need colors that communicate states.

For example:

Success
Warning
Error
Information

A basic system might look like this:

Success

Warning

Error

Info

These colors should not be chosen just because they look nice.

They need to be recognizable and work consistently across the interface.

For example:

:root {
  --success: #238636;
  --warning: #D29922;
  --error: #CF222E;
  --info: #2563EB;
}

Now an alert component can use the semantic token rather than a hard-coded color.

.alert-success {
  color: var(--success);
}

.alert-warning {
  color: var(--warning);
}

.alert-error {
  color: var(--error);
}

This is much easier to maintain.

Separate Color Values From Color Roles

This is one of the most useful changes you can make to a design system.

Instead of only having:

--green-500: #117A6A;

you can create a second layer that describes what the color is doing.

For example:

:root {
  --green-500: #117A6A;

  --color-brand: var(--green-500);
  --color-action-primary: var(--green-500);
  --color-link: var(--green-500);
}

Now the component doesn't necessarily care that the color is green.

It cares that the color represents a primary action.

That distinction becomes extremely valuable if the brand changes later.

Build Components Around the Color System

Once the tokens exist, components become easier to create.

Take a button.

Instead of this:

button {
  background: #117A6A;
  color: white;
}

you can use:

button {
  background: var(--color-action-primary);
  color: var(--color-text-on-primary);
}

Then define the tokens:

:root {
  --color-action-primary: #117A6A;
  --color-text-on-primary: #FFFFFF;
}

The component now depends on the system instead of depending on one specific hex code.

That might seem like a small difference.

It isn't.

When you have dozens or hundreds of components, this separation can save a lot of time.

What About Dark Mode?

This is another reason semantic tokens are useful.

Suppose your light theme contains:

:root {
  --color-background: #F8FAF9;
  --color-surface: #FFFFFF;
  --color-text: #17201E;
}

You can create a dark theme without changing every component individually.

[data-theme="dark"] {
  --color-background: #101614;
  --color-surface: #17201E;
  --color-text: #F4F7F6;
}

Your component can continue using:

.card {
  background: var(--color-surface);
}

body {
  background: var(--color-background);
  color: var(--color-text);
}

The component doesn't need to know whether the user is looking at light mode or dark mode.

The theme handles it.

Don't Forget Accessibility

A color system isn't complete just because the colors look good together.

You also need to check how those colors behave with actual text and interface elements.

For example, a muted text color might look elegant in a design file but become difficult to read on a real background.

Before finalizing a token, test combinations such as:

Text + Background
Button text + Button background
Link + Background
Placeholder + Input background
Focus state + Surface
Error text + Error background

And don't use color as the only way to communicate a state.

Instead of:

🔴

use:

⚠ Payment failed

Please check your payment information and try again.

The color reinforces the message instead of being the entire message.

How I Organize Color Tokens

For a smaller project, I usually keep the system fairly simple.

:root {

  /* Brand */
  --brand-500: #117A6A;
  --brand-600: #0F6E60;
  --brand-700: #0B5B50;

  /* Neutral */
  --neutral-50: #F8FAF9;
  --neutral-100: #EEF3F1;
  --neutral-200: #DDE5E2;
  --neutral-600: #66736F;
  --neutral-900: #17201E;

  /* Semantic */
  --success: #238636;
  --warning: #D29922;
  --error: #CF222E;
  --info: #2563EB;
}

Then I create role-based tokens:

:root {

  --color-background: var(--neutral-50);
  --color-surface: #FFFFFF;

  --color-text: var(--neutral-900);
  --color-text-muted: var(--neutral-600);

  --color-border: var(--neutral-200);

  --color-primary: var(--brand-500);
  --color-primary-hover: var(--brand-600);

  --color-success: var(--success);
  --color-warning: var(--warning);
  --color-error: var(--error);
  --color-info: var(--info);
}

This gives you two useful layers:

RAW COLOR
   ↓
COLOR SCALE
   ↓
SEMANTIC ROLE
   ↓
COMPONENT

For example:

#117A6A
   ↓
brand-500
   ↓
color-primary
   ↓
primary-button

That structure makes the system much easier to understand.

You Don't Have to Create Every Palette Manually

The difficult part isn't always writing the CSS.

Sometimes the difficult part is deciding which colors should actually belong in the system.

That's where palette tools can help.

You can start with a single brand color and explore different combinations before turning them into design tokens.

For example, ColorFiind can be useful during the exploration stage when you want to experiment with color combinations and build a starting palette.

I wouldn't treat a generated palette as the final answer.

I'd use it as a starting point.

The actual UI still needs to be tested with real content, real components and real accessibility requirements.

A Practical Color-System Workflow

If you're starting a new project, here's a workflow that works well:

Choose Brand Color
       ↓
Create Color Scale
       ↓
Create Neutral Scale
       ↓
Add Semantic Colors
       ↓
Define Semantic Roles
       ↓
Create Design Tokens
       ↓
Build Components
       ↓
Test Contrast
       ↓
Test Light / Dark Themes
       ↓
Document the System

The important thing is to do this before every component starts inventing its own colors.

Final Thoughts

A color system doesn't need to be complicated.

You can start with a primary color, a neutral scale and a few semantic colors.

The real improvement comes from giving those colors consistent roles.

Instead of asking:

"Which hex code should I use here?"

you can ask:

"Which color role belongs here?"

That's a much easier question to answer when your project has dozens of components.

And once the system is defined, designers and developers can work from the same visual language.

The goal isn't to have more colors. The goal is to make the colors you already have easier to use.

If you're starting from scratch, explore a few palette directions first, choose what actually works in your UI, and then turn those decisions into reusable tokens.

Explore ColorFiind and build your next palette →

How I Choose Colors for a UI Before Writing a Single Line of CSS

Ali Badshah — Wed, 19 Aug 2026 09:21:04 +0000

I used to think choosing colors was one of the easiest parts of designing a website.

Pick a nice blue. Find a darker version. Add a background color. Done.

That approach usually works for a screenshot.

It doesn't work nearly as well when you have to build the actual interface.

Once you start adding buttons, cards, forms, alerts, navigation, text, borders, hover states and different sections, those few colors suddenly aren't enough.

So before starting a new UI, I now spend a little time building a proper color system first.

Here is the process I normally follow.

1. Start With One Color

I don't start by choosing an entire palette.

I start with one color.

It could come from a logo, an existing brand, a product image or simply the visual direction I'm trying to achieve.

For example:

Primary color
#117A6A

From there, I create lighter and darker versions.

--primary-100: #DFF3EF;
--primary-300: #8CCDC3;
--primary-500: #117A6A;
--primary-700: #0B5B50;
--primary-900: #063C35;

Now I already have several options without introducing completely unrelated colors.

The lighter shades can work for backgrounds and subtle UI elements, while the darker shades can be useful for text, borders or hover states.

A palette becomes much easier to manage when every color has a job.

2. Don't Make Everything Colorful

This is probably the mistake I see most often.

A designer finds a great palette and then tries to use every color everywhere.

The result is usually a busy interface.

Most of the screen should actually be made up of neutrals.

Think about a typical dashboard.

You might have:

White or off-white background
Dark text
Light borders
Gray secondary text
White cards
One primary brand color
One or two accent colors

Something like this is already enough:

Background  → #F8FAF9
Surface     → #FFFFFF
Border      → #DDE5E2
Text        → #17201E
Muted Text  → #66736F
Primary     → #117A6A

The interesting part is that the primary color doesn't need to occupy much of the interface.

It only needs to appear where you want attention.

3. Think in Roles Instead of Hex Codes

When working on a real project, I don't want to remember what #117A6A is supposed to do.

I want to know what the color means.

For example:

Color Role	Usage
Primary	Main actions and brand elements
Secondary	Supporting interface elements
Background	Main page background
Surface	Cards and containers
Border	Separators and outlines
Text	Main content
Muted	Secondary information
Success	Completed actions
Warning	Important warnings
Error	Failed actions

This makes the palette much easier to maintain.

Instead of telling a developer:

"Use this green here."

you can say:

"Use the primary color for the main action."

That difference becomes especially useful when the project gets bigger.

4. Build the Palette Before Building Components

This is where I find color tools useful.

Instead of opening Figma and manually trying hundreds of combinations, I like to explore different relationships first.

For example:

Monochromatic

Light Green
     ↓
Green
     ↓
Dark Green

Analogous

Blue → Blue-Green → Green

Complementary

Blue ↔ Orange

Triadic

Color A
  ↘
Color B — Color C

The goal isn't to use every color relationship.

The goal is to find something that gives the interface a consistent visual direction.

5. Test the Colors on Actual UI Elements

This is the part that changed how I work with color.

A palette can look fantastic as five little squares.

Then you put those colors into an interface and realize that something is wrong.

So I create a small test screen.

Nothing complicated.

Just:

Navigation
Heading
Paragraph
Primary button
Secondary button
Card
Input field
Alert
Link

For example:

<button class="primary-button">
  Get Started
</button>

Then I test the colors against the actual component.

Sometimes a color that looked great in a palette is too bright for a button.

Sometimes a background looks fine on its own but makes text difficult to read.

Sometimes two colors look different in the color picker but almost identical when they're next to each other.

That's why the real interface is the final test.

6. Use Color to Create Hierarchy

Color shouldn't only make a design attractive.

It should help users understand what matters.

Imagine a page with three buttons:

Cancel
Save Draft
Publish

If all three buttons have exactly the same visual weight, the user has to think about which one matters most.

Instead, you can create hierarchy:

Cancel       → Text button
Save Draft   → Secondary button
Publish      → Primary button

The colors are helping communicate the importance of each action.

This is one of the reasons I prefer defining color roles before designing individual components.

7. Don't Ignore Contrast

A color can look beautiful and still be a terrible choice for text.

This happens frequently with light gray text and bright backgrounds.

For example:

color: #C8C8C8;
background: #FFFFFF;

It may look subtle and minimal.

But if users struggle to read it, the design isn't doing its job.

I check important text, buttons, links and interface states against their backgrounds before considering a palette finished.

I also try not to communicate information through color alone.

For example, instead of this:

🔴 Payment Failed

an interface could provide a clear message and an appropriate icon:

⚠ Payment failed

Please check your payment details and try again.

Color becomes an additional signal rather than the only signal.

8. Generate Shades Systematically

Once the main colors are selected, I like creating a scale.

Something like:

For example:

:root {
  --green-50:  #F1FAF8;
  --green-100: #DFF3EF;
  --green-200: #BDE5DE;
  --green-300: #8CCDC3;
  --green-400: #5BB5A7;
  --green-500: #117A6A;
  --green-600: #0F6E60;
  --green-700: #0B5B50;
  --green-800: #08483F;
  --green-900: #063C35;
}

This is much better than randomly choosing a different green every time a component needs one.

It also makes a future redesign much easier.

9. Use a Palette Generator When You Get Stuck

There is no reason to manually invent every color.

If I already know my main color, I can use a palette generator to explore different directions much faster.

For example, I can start with:

#117A6A

and explore:

Lighter shades
Darker shades
Complementary colors
Analogous colors
Accent colors
Neutral combinations

I've found ColorFiind useful for this kind of exploration because it lets you work with color combinations instead of starting from a completely blank canvas.

I still don't blindly use whatever a generator gives me.

The generator gives me ideas. The interface decides whether those ideas actually work.

10. Turn the Palette Into Design Tokens

Once the colors are final, I move them into variables.

For a web project, something like this is enough to start:

:root {
  --color-primary: #117A6A;
  --color-primary-dark: #0B5B50;

  --color-background: #F8FAF9;
  --color-surface: #FFFFFF;

  --color-text: #17201E;
  --color-text-muted: #66736F;

  --color-border: #DDE5E2;

  --color-success: #238636;
  --color-warning: #D29922;
  --color-error: #CF222E;
}

Now your components don't need to know the exact hex value.

They only need to know the role.

.button-primary {
  background: var(--color-primary);
  color: white;
}

.card {
  background: var(--color-surface);
  border: 1px solid var(--color-border);
}

That small change can save a lot of time later.

My Simple Color Workflow

If I had to reduce the whole process to a checklist, it would look like this:

Pick one primary color.
Create lighter and darker variations.
Choose neutral background and text colors.
Add semantic colors such as success, warning and error.
Choose an accent only if the interface actually needs one.
Test the colors on real UI components.
Check text and interactive element contrast.
Create reusable CSS variables or design tokens.
Test the palette on desktop and mobile.
Only then start applying it across the complete product.

Final Thought

A good color palette isn't necessarily the one with the most interesting colors.

Sometimes the best palette is surprisingly simple.

One strong primary color, a few useful variations, good neutrals, and clear semantic colors can be enough to build an entire interface.

The important thing is that the colors have a purpose.

Don't choose colors just because they look good next to each other. Choose them because they work together inside the product.

And if you're starting a new project and don't know where to begin, try building the palette first.

It can make the rest of the design process considerably easier.