A design token is a named value that records a reusable design decision, such as a text color, spacing step, corner radius, or shadow. Instead of repeating the same raw value throughout an interface, you give it a name and make components use that name or its generated output.

For example, a system might define color.text.primary as #171717. Buttons, headings, and form labels can then use the same decision. If those components actually reference the token, changing its value updates them consistently. A token alone does not change a page: the CSS, component, or tool consuming it must be connected to the token.

What design tokens are useful for

Tokens give designers and developers a shared vocabulary for visual decisions. A small set of semantic tokens can describe roles such as primary text, page background, focus ring, or card radius. Components can use those roles without needing to know why the chosen value is blue, 8 pixels, or a hard-edged shadow.

They are useful when you need to:

keep repeated UI decisions consistent across components;
change a theme without searching through every component for duplicated values;
map one design system to different implementation targets, such as CSS and a design tool;
give an AI coding tool concrete styling rules instead of relying on vague directions.

Tokens improve consistency only when the consuming code uses them. They do not automatically make a design accessible, responsive, or visually coherent; those decisions still need review.

Design token vs. CSS variable vs. Tailwind class

These terms describe different parts of the same workflow:

A design token is the named design decision, for example, color.text.primary.
A CSS custom property is one way to store a value in CSS, for example, --color-text-primary: #171717.
A Tailwind utility is a class used where a component needs the style, for example, text-foreground.

A token can be implemented as a CSS variable, a Tailwind theme variable, a JSON entry, or another platform-specific value. Those representations are related, but they are not interchangeable by default.

In Tailwind CSS v4, @theme variables define values and make matching utility classes available. Regular :root custom properties are still useful when you need a CSS value but do not want Tailwind to generate a utility for it. See Tailwind's theme variable documentation for the namespaces and behavior.

How StyleKit represents a visual style

StyleKit's per-style token maps are designed to be immediately usable in Tailwind-oriented components and AI workflows. Many entries are utility class strings, grouped into areas such as border, shadow, interaction, typography, spacing, and color. They also include required and forbidden class rules. The style metadata holds raw palette colors separately.

For example, the Neo-Brutalist map uses a responsive black border, square corners, and a hard shadow:

border: {
  width: "border-2 md:border-4",
  color: "border-black",
  radius: "rounded-none",
},
shadow: {
  md: "shadow-[4px_4px_0px_0px_rgba(0,0,0,1)] md:shadow-[8px_8px_0px_0px_rgba(0,0,0,1)]",
}

A Glassmorphism map instead uses large rounded corners, translucent surfaces, blur, and layered shadows. Applying one style's tokens to a component means the component must read and use those values; simply defining the token map does not restyle unrelated components.

This is one practical form of design tokens, but it is not a claim that every entry is a raw, platform-neutral value. For Tailwind projects, the ready-to-copy utility mappings are useful as-is. For a shared multi-platform design system, you may want to map the underlying visual decisions into semantic names and the formats required by your other tools.

Use StyleKit tokens in Tailwind CSS

You can copy a style's utility values directly into a component. This Neo-Brutalist example uses the responsive border, radius, and shadow mapping above:

<article className="border-2 md:border-4 border-black rounded-none shadow-[4px_4px_0px_0px_rgba(0,0,0,1)] md:shadow-[8px_8px_0px_0px_rgba(0,0,0,1)]">
  <h2>Project notes</h2>
  <p>Keep the visual decisions consistent across this card.</p>
</article>

If you prefer semantic utilities in a Tailwind CSS v4 app, you can map StyleKit values into your own CSS theme. This is an app-level mapping, not the same file as StyleKit's generated JavaScript config:

@import "tailwindcss";

@theme {
  --color-stylekit-accent: #ff006e;
  --shadow-stylekit-card-sm: 4px 4px 0 0 #000;
  --shadow-stylekit-card-lg: 8px 8px 0 0 #000;
}

The theme variables create utilities such as bg-stylekit-accent and shadow-stylekit-card-sm. Use them in markup:

<button class="rounded-none border-2 border-black bg-stylekit-accent px-4 py-2 text-black shadow-stylekit-card-sm md:shadow-stylekit-card-lg">
  Save changes
</button>

Tailwind CSS v4 still supports JavaScript configuration for backward compatibility, but it no longer discovers those files automatically. New v4 projects generally define and extend their theme in CSS; when using an older configuration file, load it explicitly as described in the Tailwind upgrade guide.

Use the rules with an AI coding tool

A style token map can give an AI coding tool exact class choices for borders, spacing, and component states. Required rules describe patterns to include; forbidden rules describe patterns to avoid. For example, a Neo-Brutalist prompt can ask for square corners and hard-edge shadows, while ruling out blurred shadow presets and rounded cards.

These rules narrow the implementation choices, but they cannot guarantee that generated code follows every rule or that the finished UI is usable. Review the output for mobile layouts, hover and focus states, keyboard behavior, and text contrast.

What StyleKit exports

A style page includes a token export dialog with Figma Tokens, Style Dictionary, and CSS Variables options. Those are separate output formats, so preview the selected file before assuming it contains every style rule. A full style pack also contains a Tailwind JavaScript theme config, global CSS, shadcn theme files, and an Agent Skill.

StyleKit's public API also exposes the published token map as JSON. For example, view the Neo-Brutalist token endpoint, or browse the Neo-Brutalist style page and Glassmorphism style page to compare the rules in context.

If your pipeline requires the Design Tokens Community Group's interchange format, check the target tool's importer and validate the exported file against its expected schema. The 2025.10 Design Tokens Format report is a Community Group specification; a tool-specific JSON export should not be assumed to follow that format automatically.

A practical way to start

Choose one visual style, apply its border, color, and shadow choices to a single component, and check the component at mobile and desktop sizes. Then reuse the same decisions in related components. If your project uses Tailwind CSS v4, decide which values should become semantic @theme utilities; if it needs another target, create an explicit mapping instead of assuming Tailwind class strings will work in CSS or a design tool.

To explore the rest of StyleKit, browse the visual style catalog and inspect a style's components and export options before adding it to your project.