Design Token & Color System Generator

What Are Design Tokens and Why Do They Matter?

Design tokens are the atomic values that define a visual design system: colors, spacing, typography, and elevation. They bridge the gap between design intent and code implementation by providing a single source of truth that both designers and developers reference. When a brand color changes, updating one token propagates the change everywhere — across components, themes, and platforms. Design tokens are format-agnostic: the same semantic meaning (e.g., “primary-500”) maps to CSS custom properties in web projects, SwiftUI color assets in iOS, and XML resources in Android. The W3C Design Tokens Community Group is standardizing a JSON format so tools can exchange token files without conversion. Adopting tokens early prevents the accumulation of one-off hex values scattered through stylesheets, which is one of the most common sources of visual inconsistency in large codebases.

Building a Tonal Scale: The Science Behind 50–900 Steps

A tonal scale maps a single hue to ten lightness steps, producing a coherent range from near-white (50) to near-black (900). The algorithm works in HSL color space: step 500 anchors on the input color, lighter steps increase lightness while gently reducing saturation to avoid washed-out pastels, and darker steps decrease lightness while slightly boosting saturation to maintain vibrancy. This mirrors how Tailwind CSS, Material Design, and Chakra UI build their palettes. The resulting scale gives designers predictable options for backgrounds (50–100), borders (200–300), body text on light backgrounds (700–900), and interactive states like hover (600) and pressed (700). Consistency across the scale ensures that swapping a primary blue for a primary green preserves the same visual hierarchy without manual adjustments.

Semantic Tokens: From Raw Values to Meaningful Names

Raw color values like #3B82F6 carry no meaning. Semantic tokens wrap those values in purpose-driven names: --color-primary-base, --color-error-surface, --color-success-on. Each semantic category (primary, secondary, success, warning, error, info) includes six variants: base for default state, hover for pointer interaction, pressed for active/click state, disabled for inactive elements, surface for lightweight tinted backgrounds, and on-color for text rendered on top of the base color. This mapping lets components reference var(--color-primary-hover) without knowing the exact hex, making theme switches and white-label customization trivial.

Dark Mode: More Than Inverting Colors

Effective dark mode is not simply swapping black and white. Dark backgrounds require lower saturation to reduce eye strain, elevated surfaces need lighter shades to convey depth, and text contrast must meet APCA (Advanced Perceptual Contrast Algorithm) thresholds that account for how human vision perceives luminance on dark versus light backgrounds. The APCA model, proposed for WCAG 3.0, recognizes that dark text on white and white text on dark are not perceptually equivalent at the same contrast ratio. This tool generates dark mode tokens with those adjustments baked in, producing a ready-to-use override block for [data-bs-theme="dark"] or a Tailwind dark: variant layer.

WCAG 2.1 Contrast Requirements Explained

The Web Content Accessibility Guidelines (WCAG) 2.1 define contrast ratios as the relative luminance of the lighter color plus 0.05, divided by the relative luminance of the darker color plus 0.05. Level AA requires a minimum 4.5:1 ratio for normal text (under 18pt or 14pt bold) and 3:1 for large text. Level AAA raises the bar to 7:1 and 4.5:1 respectively. Non-text UI components (icons, borders, form controls) need at least 3:1 against adjacent colors. The accessibility matrix in this tool cross-references every generated foreground and background combination so you can identify compliant pairs at a glance, eliminating trial-and-error during the design process. Meeting these ratios is not just a legal requirement under accessibility laws in many jurisdictions — it directly improves readability for all users, especially in suboptimal lighting conditions.

Export Formats: CSS, Tailwind, SCSS, and W3C JSON

This generator outputs tokens in four formats simultaneously. CSS custom properties (:root { --color-primary-500: #3B82F6; }) work natively in any browser and can be overridden per-component or per-theme. Tailwind config objects slot into theme.extend.colors for utility-class generation. SCSS variable maps ($color-primary-500: #3B82F6;) integrate with Sass-based build pipelines and support map-get lookups. The W3C Design Tokens JSON format follows the Community Group specification, using $value and $type keys so tools like Style Dictionary, Tokens Studio, and Figma plugins can consume the file directly. Choosing the right format depends on your tech stack, but generating all four ensures your design system is portable across any toolchain.

Integrating Tokens Into Your Workflow

Once exported, design tokens fit into a continuous integration pipeline. Store the JSON token file in your repository, run Style Dictionary or a similar transformer in CI, and output platform-specific files (CSS for web, XML for Android, Swift for iOS) automatically. Changes to the source tokens trigger regeneration across all platforms, ensuring pixel-level consistency. For Figma-to-code workflows, the W3C JSON format exported here is directly compatible with Tokens Studio, allowing designers to push token updates that developers pull into their build without manual handoff. This closed loop eliminates the “it looks different in production” class of bugs and reduces the surface area for design-to-development miscommunication.