Picking colours for a website feels like it should be simple. Choose a brand colour, add a few neutrals, throw in a green for success and a red for errors, done.
In practice, building a colour system that works across light mode, dark mode, every interactive state, every component variation, and every accessibility requirement is one of the deepest problems in web design. It touches colour science, accessibility standards, design token architecture, and CSS engineering simultaneously. Let us get into it.
Why HSL Is Not Enough (Use OKLCH)
Most developers think about colour in HSL — hue, saturation, lightness — because CSS makes it convenient. The problem is that HSL is not perceptually uniform. A yellow at 50% lightness looks dramatically brighter to the human eye than a blue at 50% lightness.
This means you cannot generate a palette by simply stepping through lightness values and expect consistent visual results. The OKLCH colour space fixes this. OKLCH is perceptually uniform — equal steps in lightness produce equal changes in perceived brightness regardless of hue.
CSS now supports oklch() natively, and it is the single best improvement in CSS colour handling in the last decade. If you are building a colour system in 2026 and not using OKLCH, you are working harder than you need to.
Colour Scale Structure: The 50–950 Convention
Every colour in your system needs a scale — typically 10 steps from lightest to darkest. Tailwind uses the 50–950 convention: slate-50 is nearly white, slate-950 is nearly black.
Each step serves a purpose. The lightest values (50–100) are for backgrounds and subtle fills. The mid values (400–600) are for borders, icons, and secondary text. The darkest values (700–950) are for primary text and high-contrast elements.
In dark mode, this entire scale inverts — backgrounds use the 900–950 range, text uses the 50–200 range. If your scale was generated with perceptual uniformity in mind, this inversion works naturally. If it was hand-picked from a colour picker, it will feel off.
WCAG Contrast Ratios Are Not Negotiable
WCAG 2.1 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. WCAG 2.2, now the standard, maintains these requirements and adds criteria for focus indicators. This is not optional — it is a legal requirement in many jurisdictions and a fundamental accessibility baseline.
Practically, this means your light grey text on a white background does not meet contrast requirements, even if it "looks fine" on your high-end display. Use a contrast checker. We check every text-background combination during design review, and you would be surprised how many popular websites fail basic contrast on their body text.
Semantic Colour Tokens
Raw colour values should never appear in component code. Instead, define semantic tokens that describe purpose: foreground, background, muted, border, primary, secondary, destructive, success, warning.
Each semantic token maps to a step in your colour scale, and that mapping changes between light and dark mode. Your component code references the semantic token, never the raw colour. A button styled with bg-primary works in both modes without conditional logic, because the primary token resolves to different values in each context.
The Grey Problem
Greys are the most important colours in your system and the easiest to get wrong. Pure grey — equal RGB values — looks lifeless and slightly cold. Most design systems use warm greys (Tailwind's stone scale) or cool greys (Tailwind's slate scale) depending on the brand feel.
The critical thing is to use one grey scale consistently. Mixing warm and cool greys in the same interface creates a subtle visual discord that users feel but cannot articulate. Pick one. Commit. Use it everywhere.
Integrating Your Brand Colour
Your brand colour needs to work at every step of the scale, in both light and dark modes, at every contrast ratio. This is harder than it sounds — a vibrant orange that looks great on white might need a completely different shade on a dark background to stay readable.
Start by placing your brand colour at the 500–600 mark of your scale, then generate lighter and darker variants in OKLCH by adjusting the lightness channel while keeping hue and chroma consistent. This produces a cohesive scale that feels like a natural extension of the brand, rather than arbitrary lighter and darker versions.
State Colours and Interaction Feedback
Every interactive element needs at least four colour states: default, hover, active, and disabled. For primary buttons, that typically means default at 600, hover at 700, active at 800, and disabled at a muted variant with reduced opacity. For borders: default at 200, hover at 300, focus at the primary colour.
Define these state transitions in your token system so every component handles interactions consistently. Ad hoc state colours are how you end up with fifteen different hover blues across your application.
Data Visualisation Colours
If your application includes charts or dashboards, you need categorical colours that are visually distinct from each other and from your UI colours. They must remain distinguishable for users with colour vision deficiencies — roughly 8% of men and 0.5% of women.
Use a palette checker that simulates deuteranopia, protanopia, and tritanopia. If two categories are indistinguishable under any of those simulations, pick different colours.
How Colour Systems Drive Conversions
Colour is not just aesthetics — it is conversion infrastructure. A primary CTA that contrasts cleanly with everything around it gets seen and clicked; one that blends into a muddy palette gets scrolled past. Compliant contrast on body text keeps visitors reading instead of squinting and leaving.
Consistent state colours make interfaces feel trustworthy, and trust is what converts. This is why colour systems sit inside the broader discipline of conversion-focused web design — every token decision either helps or hinders a visitor's path to action. It is also core to our UX design work, where accessibility and hierarchy get engineered rather than eyeballed.
The Verdict
A well-built colour system is invisible. Users do not notice that the greys are warm, that the contrast ratios are compliant, or that the dark mode inversion is seamless. They just feel that the interface is professional, readable, and comfortable.
That invisible quality is the mark of a colour system that was engineered, not guessed at. Build the system once, and every screen you ship afterwards inherits the quality.