Why chart colors are different
Your UI accent color is optimized for one thing: standing out against the background. Chart colors solve a completely different problem. They need to be distinguishable from each other. A five-series bar chart needs five colors that a user can tell apart instantly, even at small sizes, even in a legend, even when printed in grayscale.
This is why you cannot just pull from your existing color scale. Using blue-400, blue-500, blue-600 for three chart series looks cohesive in a Figma mockup and completely unreadable in a real dashboard where someone is trying to compare values.
Chart tokens need to be a separate token set with its own design constraints.
The five-color minimum
Most dashboards need between three and seven distinct chart colors. Five is the sweet spot. It covers pie charts, stacked bars, multi-line graphs, and area charts without overwhelming the viewer. Go above seven and human perception struggles to map colors to categories reliably.
/* Chart token set: 5 colors */
:root {
--chart-1: #6366F1; /* indigo - primary series */
--chart-2: #06B6D4; /* cyan - secondary series */
--chart-3: #F59E0B; /* amber - tertiary */
--chart-4: #10B981; /* emerald - quaternary */
--chart-5: #F43F5E; /* rose - quinary */
}The key principle: maximize hue distance. Each color should occupy a different region of the color wheel. Indigo, cyan, amber, emerald, and rose are roughly evenly spaced around the hue circle, which means they remain distinguishable even to viewers with partial color vision.
Light mode vs dark mode chart colors
Chart colors that work on a white background often fail on a dark background. The issue is contrast. A vibrant amber on white has plenty of contrast. The same amber on near-black can feel washed out, or worse, the chart lines become invisible against dark grid lines.
/* Light mode chart tokens */
:root {
--chart-1: #4F46E5; /* deeper indigo on white */
--chart-2: #0891B2; /* deeper cyan */
--chart-3: #D97706; /* deeper amber */
--chart-4: #059669; /* deeper emerald */
--chart-5: #E11D48; /* deeper rose */
}
/* Dark mode chart tokens */
.dark {
--chart-1: #818CF8; /* lighter indigo on dark */
--chart-2: #22D3EE; /* lighter cyan */
--chart-3: #FBBF24; /* lighter amber */
--chart-4: #34D399; /* lighter emerald */
--chart-5: #FB7185; /* lighter rose */
}The pattern: darker, more saturated values for light backgrounds. Lighter, slightly desaturated values for dark backgrounds. The hues stay the same. Only the lightness shifts. This keeps the chart identity consistent across themes while maintaining readability. For more on building robust dark mode systems, see dark mode color system.
Accessibility requirements for chart colors
3:1 contrast against the background
WCAG requires a minimum 3:1 contrast ratio for graphical objects (which includes chart elements). Every chart color must hit this threshold against your chart's background surface. This is the same surface token (--color-surface) from your design system, not --color-bg, since most charts render inside cards or panels.
Distinguishability without color alone
Color vision deficiency affects roughly 8% of males and 0.5% of females. Your chart cannot rely on color alone to convey information. This means patterns, labels, or direct annotations matter as much as the palette. But a well-chosen palette reduces the burden on those secondary indicators.
The hue-spacing approach (indigo, cyan, amber, emerald, rose) works well for the three most common forms of color vision deficiency because it distributes colors across both the blue-yellow and red-green axes. Avoid combining red and green as adjacent series. Avoid combining blue and purple without a third distinguishing factor.
Wiring chart tokens to libraries
Recharts
Recharts accepts colors as props or via CSS. The cleanest approach is referencing your CSS variables directly through a helper.
/* Helper to resolve CSS variable values */
const getChartColor = (index: number) =>
getComputedStyle(document.documentElement)
.getPropertyValue(`--chart-${index}`).trim();
/* Usage in Recharts */
<Bar dataKey="revenue" fill={getChartColor(1)} />
<Bar dataKey="expenses" fill={getChartColor(2)} />
<Bar dataKey="profit" fill={getChartColor(3)} />Chart.js
Chart.js supports CSS variable references in its dataset configuration. You can pass the variable names directly if your Chart.js version supports it, or resolve them at render time.
const chartConfig = {
datasets: [{
label: 'Revenue',
backgroundColor: 'var(--chart-1)',
borderColor: 'var(--chart-1)',
}, {
label: 'Costs',
backgroundColor: 'var(--chart-2)',
borderColor: 'var(--chart-2)',
}]
};Tremor
Tremor (the React dashboard library built on Tailwind) uses a named color system. You can map your chart tokens to Tremor's color props by extending your Tailwind theme.
/* In your CSS with Tailwind v4 */
@theme {
--color-chart-1: var(--chart-1);
--color-chart-2: var(--chart-2);
--color-chart-3: var(--chart-3);
--color-chart-4: var(--chart-4);
--color-chart-5: var(--chart-5);
}Beyond the five base colors
Some dashboards need more than five series. When you go beyond five, derive additional colors rather than picking entirely new hues.
The opacity variant pattern
Use your existing chart colors at reduced opacity to create a second tier. --chart-1 at 60% opacity becomes a visually distinct but related color. This works especially well for stacked area charts where overlapping series benefit from transparency.
/* Extended chart palette using opacity */
--chart-6: oklch(from var(--chart-1) l c h / 0.6);
--chart-7: oklch(from var(--chart-2) l c h / 0.6);
--chart-8: oklch(from var(--chart-3) l c h / 0.6);The lightness shift pattern
Alternatively, create lighter or darker variants of your base chart colors. Shift lightness by 15-20% to create a clearly distinct sibling.
Dashboard surface tokens
Charts live inside dashboards, and dashboards have their own token needs beyond chart colors. A well-tokenized dashboard defines surfaces for the overall page, individual metric cards, chart containers, and data table rows.
/* Dashboard-specific surface tokens */
--dashboard-bg: var(--color-bg);
--dashboard-card: var(--color-surface);
--dashboard-card-hover: var(--color-surface-hover);
--dashboard-grid-line: var(--color-border);
--dashboard-axis-label: var(--color-muted);
--dashboard-tooltip-bg: var(--color-surface);
--dashboard-tooltip-border: var(--color-border);These reference your core semantic tokens, so they automatically adapt to theme changes. The grid lines use your border color. The axis labels use your muted text. The tooltip matches your surface. Everything stays coherent without any chart-specific overrides. To understand the full token layering pattern, see Tailwind color palette ideas.
SeedFlip includes chart tokens
Every SeedFlip seed ships with five chart colors (chart-1 through chart-5) that are curated to work with the seed's palette. They are hue-spaced, contrast-checked against the seed's surface color, and shift appropriately between light and dark variants.
/* SeedFlip seed: chart colors included */
{
"chart-1": "#6366F1",
"chart-2": "#06B6D4",
"chart-3": "#F59E0B",
"chart-4": "#10B981",
"chart-5": "#EC4899",
/* ...alongside bg, surface, text, accent, etc. */
}You do not have to invent chart colors from scratch and then verify they work with your palette. The seed handles that curation. Export to CSS variables, Tailwind config, or shadcn/ui theme, and your charts inherit the same design language as the rest of your product. Check design variables that actually matter for the full list of tokens every product needs.
Chart colors are not an afterthought. They are a first-class design token set that demands the same rigor as your UI tokens. Maximize hue distance, check contrast in both themes, keep the set small, and extend with opacity or lightness variants when needed. Build the chart layer once, wire it to your charting library, and never hand-pick a chart color again.