Skip to content
Color Token Generator
Tools

Color Token Generator

Novo

Generate a full design-token scale (50–950 shades) from a single base color — CSS, Tailwind or JSON.

  

Runs entirely in your browser. Nothing is uploaded.

Why every design system needs a color scale

A color scale is the backbone of a consistent visual language. Without it, designers and developers make ad-hoc decisions — 'a slightly darker blue for hover' or 'a very light version for the card background' — that produce dozens of nearly-identical hex values with no systematic relationship. Over time this creates a codebase full of one-off color values that are impossible to update in one go.

A properly constructed 11-stop scale solves this: light stops (50–200) serve tinted surfaces and backgrounds, mid stops (300–600) carry interactive elements like buttons, links, and focus rings, and dark stops (700–950) handle text and high-contrast borders. Every decision traces back to the scale, and changing the brand color means updating one base value rather than hunting through hundreds of hex codes in a stylesheet.

The Tailwind color scale convention

Tailwind CSS popularized the 11-stop numeric naming convention — 50, 100, 200 through 900, 950 — and it has since been adopted as the standard by Radix UI, shadcn/ui, Material Design 3, and most modern component library ecosystems. The advantage is predictability: a developer who has used any of these systems immediately knows that a 500-level token is the mid-range base color, a 100-level token is a very light tint, and an 800-level token is a dark shade for use on light backgrounds.

This tool generates scales that are visually compatible with Tailwind's built-in palettes (blue, red, green, etc.), making it straightforward to add a custom brand color that integrates naturally alongside Tailwind's defaults. The Tailwind export format matches exactly what theme.extend.colors expects in tailwind.config.js, and the CSS Variables export is formatted for Tailwind v4's @theme block.

Understanding WCAG contrast ratios

The contrast ratio between a text color and its background is calculated from their relative luminance — a measure of how bright each color appears to the human eye. The WCAG formula is (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter color's luminance and L2 the darker. The result ranges from 1:1 (identical colors, no contrast) to 21:1 (black text on white background, maximum contrast).

WCAG AA requires 4.5:1 for normal text and 3:1 for large text (18pt+). WCAG AAA requires 7:1 for normal text. In this tool, each swatch's white-text and black-text contrast ratios are computed and shown as W✓ and B✓ badges. Mid-scale stops (400–600) typically fail both thresholds — they're designed for decorative fills and interactive accents, not text backgrounds. Accessible text pairings live at the extremes: very light stops for dark text, very dark stops for white text.

Color spaces: HSL, OKLCH, and why it matters

Traditional palette generators work in HSL — Hue, Saturation, Lightness. HSL is intuitive and well-supported, but perceptually non-uniform: the same numeric lightness step looks dramatically different depending on the hue. A step from 50% to 60% lightness looks like a big jump for blue but a tiny step for yellow, because the human eye perceives colors differently across the spectrum.

OKLCH is a perceptually uniform color space where equal numeric lightness steps look equal to the human eye regardless of hue. Tailwind CSS v4 switched to OKLCH internally for this reason. For a palette generator, OKLCH produces scales where each stop genuinely looks like an even step toward lighter or darker — especially valuable for accessible palette design where consistent perceptual steps are needed to reliably predict contrast ratios across the full scale.

Exporting to CSS, Tailwind, SCSS, JSON, and DTCG

The CSS Variables export uses the --color-N naming pattern inside :root { }. The Tailwind export drops directly into theme.extend.colors in tailwind.config.js — rename 'color' to your token name (e.g., 'primary' or 'brand'). The SCSS export uses $color-N variable syntax compatible with Sass and Less. The JSON export follows the W3C DTCG token format and is compatible with Style Dictionary, Theo, Supernova, and any tool in the modern token pipeline ecosystem.

All four formats output the same 11 hex values, so switching between them after generation requires no changes. Click any individual swatch to copy its hex value directly to the clipboard — useful when you need a single specific shade for a Figma design file, a one-off inline style, or a quick color reference without running a full export.

How this compares to Coolors, Adobe Color, and Material Design Color Tool

Coolors.co is a palette discovery tool designed to generate random 5-color combinations. It's excellent for inspiration but doesn't produce token scales, doesn't output Tailwind configs, and doesn't show per-swatch WCAG contrast badges. You can export hex values, but you get five independent colors — not a structured dark-to-light ramp from a single hue.

Adobe Color offers color harmony generation from a color wheel and some export options, but it requires an Adobe account to save and export palettes. It doesn't generate a Tailwind-compatible color scale or DTCG JSON, and it lacks per-stop contrast ratio display.

Google's Material Design Color Tool produces a 10-stop scale (missing the 50 stop) and is designed specifically for Material Design theming — the output doesn't map cleanly to Tailwind or other ecosystems. It also lacks DTCG and SCSS export formats.

This tool generates a full 11-stop scale, shows WCAG W✓/B✓ badges on every swatch, exports to four formats, and requires no login. Everything runs in your browser — no color data is uploaded to a server.

Design tokens: the concept and the three-tier model

Design tokens were coined by Jina Anne in 2014 during the development of Salesforce's Lightning Design System — defined as the smallest, indivisible design decisions stored as data rather than hard-coded values. Before tokens, color values like #3b82f6 were scattered across thousands of CSS files. Changing the brand color meant a find-and-replace across the entire codebase — an error-prone process that inevitably left stale values in corners of the product. Tokens solve this by giving semantic names to values that can be updated in one place and propagated everywhere automatically.

The industry has converged on a three-tier token architecture. The first tier — global or primitive tokens — stores raw values with no semantic meaning: color-blue-500: #3b82f6. These are the full palette, every shade, every hue. The second tier — semantic tokens — creates context-based aliases into the primitive layer: color-action: {color-blue-500}. Semantic tokens communicate intent, not appearance. The third tier — component tokens — maps semantic tokens to specific UI elements: button-background: {color-action}. This indirection means you can retheme the entire product by updating semantic token mappings without touching any component code.

This three-tier model is what makes a color scale generator a token generator rather than just a palette tool. The 11-stop scale this tool produces is the primitive tier. Your design system's semantic layer decides which stop becomes --color-primary, which becomes --color-primary-hover, and which becomes --color-primary-subtle-surface — and those decisions can be changed at any time without touching components.

The design token ecosystem: Style Dictionary, DTCG, and Figma Variables

Style Dictionary, open-sourced by Amazon in 2017, is the most widely used tool for transforming design tokens from a platform-neutral JSON format into platform-specific outputs: CSS custom properties, SCSS variables, Swift constants for iOS, Android XML resource files, and JavaScript/TypeScript modules. A single DTCG JSON file — the kind this tool exports — can be fed into Style Dictionary to generate every platform's token file simultaneously, keeping all platforms in sync from one source of truth.

The W3C Design Token Community Group (DTCG) specification, active since 2020, standardizes the token file format so that Figma, Style Dictionary, Supernova, Theo, and other tools can all consume the same JSON without custom transformation. The DTCG format attaches a $type annotation to each token — "$type": "color" for color values — allowing tools to validate and transform tokens correctly. Before DTCG, each tool had its own JSON shape, making it painful to switch or combine tools. The JSON export from this color scale generator follows the DTCG schema precisely.

Figma Variables, launched in 2023, is Figma's native token system. Designers can define primitive, semantic, and component color tokens directly in Figma files and reference them across components — the same three-tier model described above, but living inside the design tool. Figma Variables export to code via plugins that output DTCG-compatible JSON, completing the loop: designers work with tokens in Figma, engineers consume the same tokens in CSS via Style Dictionary, and a color scale generator like this one produces the primitive palette both sides start from.

CSS custom properties as runtime tokens

CSS custom properties — also called CSS variables — are the native mechanism for implementing design tokens at runtime in browsers. A token is declared as --color-primary: #3b82f6; on the :root selector and consumed anywhere in the stylesheet with background-color: var(--color-primary);. Unlike SCSS or Less variables (which are resolved at compile time and disappear into the output CSS), custom properties exist in the live DOM and can be read and modified by JavaScript at runtime. This makes them the foundation for features like user-selectable themes and real-time color customization without a page reload.

Custom properties follow the normal CSS cascade and inheritance rules — they can be scoped to any selector and will override the root definition for everything inside that scope. Dark mode is the canonical use case: declare --color-background: #ffffff; in :root and override it with --color-background: #0f0f0f; inside @media (prefers-color-scheme: dark) or a .dark class. Every component that uses var(--color-background) automatically responds to the override without changing any component code. This is precisely the pattern that makes three-tier token architecture operationally practical.

The @property rule (CSS Houdini) extends custom properties further: by declaring a property as syntax: '<color>', the browser treats it as a typed color value rather than a text substitution. This unlocks CSS transitions and animations of color tokens — something impossible with un-typed custom properties, where the browser doesn't know it's looking at a color and therefore can't interpolate between two values. Typed custom properties also improve performance by eliminating reparsing and allow CSS color-mix() and oklch() functions to operate on the token value directly.

Semantic naming conventions and real-world color systems

The most dangerous token naming pattern is named-color tokens: --color-blue: #0000ff. These feel clear at definition time but become lies the moment the brand evolves. If the primary action color changes from blue to teal, every component that references --color-blue now receives the wrong value — and the token name has become misinformation baked into the codebase. The fix is semantic roles: --color-primary, --color-secondary, --color-success, --color-warning, --color-error, --color-neutral. These communicate intent, not appearance, and remain accurate when the palette changes.

Production design systems extend semantic naming further with the surface/content pattern. Surface tokens describe layers of the UI's background hierarchy: --color-surface-default, --color-surface-raised (cards, dropdowns), --color-surface-overlay (modals, popovers). Content tokens describe the text and icon layer on top: --color-content-primary, --color-content-secondary, --color-content-disabled. This vocabulary maps directly to how designers think about a screen's visual stack and makes it unambiguous which token to use in any situation — no guessing whether a card background should use stop 50 or stop 100.

Radix UI's color system is the most widely studied reference implementation of this approach. It defines 12-step color scales where each step number carries an explicit semantic role: steps 1–2 for page and component backgrounds, steps 3–5 for interactive UI element backgrounds (idle, hover, active), steps 6–8 for borders and separators, steps 9–10 for solid interactive fills (buttons, badges), and steps 11–12 for accessible text. This explicit step-to-role contract means any developer can apply any Radix color correctly without reading documentation. The 11-stop scale this tool generates (50 through 950) maps closely to the Radix 12-step model, giving you the same semantic clarity with Tailwind-compatible numeric keys.

Frequently asked questions

What are design tokens?

Design tokens are named variables that store visual design decisions — colors, spacing, typography, shadows — in a format that can be shared across platforms and tools. A color token like '--color-brand-500: #7c3aed' can be used identically in web CSS, iOS Swift, Android XML, and React Native. They are the foundation of scalable, multi-platform design systems and are now standardized under the W3C Design Token Community Group (DTCG) format. Tools like Style Dictionary and Supernova consume DTCG JSON directly for automated token pipelines.

What is an 11-stop color scale?

An 11-stop scale defines 11 shades of a color numbered 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, and 950. Stop 50 is near-white (97% lightness), stop 500 is the base mid-tone, and stop 950 is near-black (8% lightness). Tailwind CSS established this convention and it's now the standard for design systems including Radix UI, shadcn/ui, Material Design 3, and most enterprise component libraries. Most other palette generators only produce 5 or 10 stops, meaning you end up without the 50 and 950 stops needed for subtle surface fills and near-black text.

How are the scale stops generated?

The generator converts your hex color to HSL (hue, saturation, lightness) and maps your color's hue to each stop with a predefined perceptual lightness curve: 97% at stop 50, down to 8% at stop 950. Saturation is slightly reduced at darker stops to avoid overly vivid shadows, matching the visual behavior of Tailwind's built-in palettes. This produces a scale where each stop looks like a natural tint or shade of your base color. Unlike Coolors.co, which generates random 5-color combinations, this tool creates a systematic ramp from a single base color — giving you a real design-token-ready output.

What is the difference between HSL and OKLCH color spaces?

HSL (Hue, Saturation, Lightness) is the traditional color model used by most palette generators. It's simple and fast but perceptually non-uniform — equal numeric lightness changes in HSL don't always look equally bright to the human eye. OKLCH is a newer perceptually uniform color space where equal lightness steps produce equal perceived brightness across all hues. Tailwind v4 now uses OKLCH internally for more consistent palettes, especially across very different hues like yellow and blue. Adobe Color still defaults to HSL-based generation and does not offer OKLCH export.

What does the W✓ / B✓ badge on each swatch mean?

W✓ means white text passes the WCAG AA contrast threshold of 4.5:1 on that swatch. B✓ means black text passes 4.5:1 on that swatch. If neither badge appears, both white and black text fail AA — the swatch is only appropriate for decorative purposes or large-format text (which requires only 3:1). Checking these badges before assigning text colors prevents accessibility violations before they reach production. Most competing tools like Coolors.co and Material Design Color Tool don't show per-swatch WCAG badges inline, so you'd need a separate contrast checker to verify each stop.

What is WCAG and why does contrast matter?

WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility, published by the W3C. The AA level requires a contrast ratio of at least 4.5:1 for normal text (under 18pt) and 3:1 for large text (18pt+ or 14pt+ bold). Insufficient contrast makes text unreadable for users with low vision, color vision deficiency, or in bright outdoor environments. In many jurisdictions, WCAG AA compliance is also a legal requirement for public-facing websites under the ADA and EN 301 549.

How do I use the Tailwind export in my project?

Copy the Tailwind export and paste it inside the theme.extend.colors object in your tailwind.config.js, renaming 'color' to your token name (e.g., 'brand' or 'primary'). For Tailwind v4 with the CSS-first @theme block, use the CSS Variables export instead and paste it inside your @theme { } declaration using the pattern --color-brand-500: #hex; — Tailwind v4 reads CSS custom properties directly without a JavaScript config file. This works on every device including iPhone and Android, since there is nothing to install.

How do I use the CSS Variables export?

Paste the CSS Variables export inside a :root { } block in your global stylesheet. Every stop becomes a custom property like --color-500: #7c3aed that you can reference anywhere in your CSS with var(--color-500). Rename 'color' to your token name for clarity. These properties cascade normally, so you can override specific stops inside component-scoped selectors or dark-mode media queries. No build tool required — this is plain CSS that works in every modern browser.

Can I generate palettes for neutral grays?

Yes. Enter any hex close to #6b7280 for a clean gray. The low HSL saturation produces a neutral ramp with minimal color cast. For warm neutrals (the slightly brownish grays popular in modern UI design — think Tailwind's stone or sand palettes), enter a hex with a hue around 25–40 degrees and 6–12% saturation. For cool grays (slate-like), use a hue in the 210–230 degree range.

Why are the light stops (50, 100) not pure white?

Tinted light stops are far more practical in real UIs than pure white — they create visible surface hierarchy between background, card, and input levels without looking dirty or accidental. Pure white (#ffffff) has no color identity and makes it impossible to distinguish between surface layers. The 50 and 100 stops at 97% and 93% lightness are light enough to read as 'nearly white' while still being clearly connected to your brand hue.

What is the W3C DTCG (Design Token Community Group) format?

The DTCG format is an emerging W3C standard for interoperable design tokens, defining how tokens should be structured in JSON so that tools like Figma, Style Dictionary, Theo, and Supernova can all consume the same token file without custom transformation. The JSON export from this tool follows the DTCG shape with type annotations, making it compatible with style-dictionary and other token pipeline tools.

How do I pick the right stop for button colors, text, and backgrounds?

The general rule: light stops (50–200) work for tinted backgrounds, table row stripes, and subtle surface fills. Mid stops (300–500) work for button fills, focus rings, and interactive accents on light backgrounds. Dark stops (600–800) work for hover states on mid-stop buttons and text on very light backgrounds. Very dark stops (900–950) work for text and high-contrast borders. Use the W✓/B✓ badges to verify contrast for any text-bearing application.

How does this compare to Coolors.co and Adobe Color?

Coolors.co is a palette discovery tool — great for generating random 5-color combinations, but it doesn't produce structured token scales or CSS export. Adobe Color generates harmonies from a color wheel but requires an Adobe account to export tokens, and doesn't output Tailwind configs or DTCG JSON. This tool is built specifically for the design-token use case: put in one hex and get back a standards-compliant 11-stop scale with four export formats and per-swatch WCAG contrast badges, all without logging in or uploading anything.