Design Tokens Export: From Brand Kit to Code

Design tokens are the smallest unit of a design system: a color, a font size, a spacing value, a font family. Exporting tokens from a brand kit to actual code means the same values appear in your design tool, your CSS, and your runtime components. This article walks through the export pipeline: the token hierarchy, the six export formats, a worked example, and the mistakes to avoid.

What Design Tokens Are

A design token is a named value, not a raw value. The raw value #2563eb is just a color. The token color.brand.primary is a design decision with intent. Tokens move design decisions out of one-off CSS and into a structured layer that every component reads from.

The W3C Design Tokens Format Module is the working draft that defines a standard JSON structure for tokens. The FontBlend brand kit exporter follows the W3C structure for the JSON export, so the tokens you export are portable to any tool that reads the W3C format.

The Token Hierarchy

A clean token system has three layers.

Global tokens are the raw values. color-blue-500, font-size-16, space-4. These are the palette of options.

Alias tokens reference global tokens with a semantic name. color-brand-primary points to color-blue-500. text-body points to font-size-16. Aliases capture the decision: this is the brand color, this is the body size.

Component tokens reference alias tokens with a component-scoped name. button-background points to color-brand-primary. card-padding points to space-4. Component tokens let a component change without touching the alias layer.

The three layers keep raw values, decisions, and component choices separate. A rebrand changes the alias layer. A button redesign changes the component layer. The raw values stay fixed.

The Six Export Formats

The FontBlend brand kit exporter ships six formats from the same source data.

CSS variables: a single tokens.css file with every token as a --token-name custom property on the :root selector. This is the format most web projects consume.

SCSS: a _tokens.scss file with every token as a SCSS variable ($token-name) and a map for iteration. This suits teams that still use SCSS.

Tailwind config: a tailwind.tokens.js file that extends the Tailwind theme with the brand colors, fonts, and sizes. Drop it into your tailwind.config and the tokens become utility classes.

JSON: a W3C-format tokens.json file. This is the format design tools (Figma Tokens Plugin, Token Studio) read directly. It is the source of truth for cross-tool portability.

Markdown: a DESIGN.md file with the brand kit documented as readable prose. This is the format you ship to engineers, contractors, and brand reviewers who do not read JSON.

SVG: a palette.svg file with labeled swatches for every color role in the kit. This is the format you drop into a brand guidelines document or a slide deck when the team needs to see the kit, not parse it.

A Worked Example

Take a brand kit built in FontBlend with these values: primary color oklch(0.6 0.2 250), body font Inter, body size 16px, heading size 32px, body weight 400, heading weight 700. Export the kit as CSS variables and you get --color-brand-primary: oklch(0.6 0.2 250), --font-body: "Inter", system-ui, sans-serif, --font-size-body: 16px, --font-size-heading: 32px, --font-weight-body: 400, --font-weight-heading: 700. Export the same kit as Tailwind config and the same values land in the theme.extend.colors, theme.extend.fontFamily, theme.extend.fontSize, and theme.extend.fontWeight keys. The same source, two formats, zero drift.

How to Consume the Tokens in a Real Project

In a CSS-variables project, import tokens.css in your entry stylesheet, then write component CSS like background: var(--color-brand-primary);. In a Tailwind project, merge the generated tailwind.tokens.js into your config, then use the utilities (bg-brand-primary, text-body). In a React or Vue project, import the JSON tokens directly into your theme module if you need runtime access.

The rule is one source of truth. Edit the brand kit in FontBlend, export the tokens, commit them to your repo. Do not hand-edit the generated files. The next rebrand overwrites them.

Common Mistakes

Hardcoding values instead of using tokens is the most common mistake. A developer writes color: #2563eb because it is faster than looking up the token name. Six months later, the brand changes primary blue and that component does not update. Use the token, even when it is slower.

Inconsistent naming is the second mistake. color-primary in CSS, primaryColor in JavaScript, brand_main in the design tool. Pick one naming convention (kebab-case for CSS, camelCase for JS) and stick to it across every export.Skipping the alias layer is the third mistake. Components reference global tokens directly, so a rebrand requires touching every component. The alias layer exists to absorb rebrands. Use it.

Naming Is the Whole Job

A token system lives or dies on its names, because names are the interface the team codes against. Decide the convention once and enforce it across every export. Kebab-case names such as color-brand-primary read naturally in CSS variables and JSON keys; if the JavaScript side needs camelCase, generate it from the same source rather than retyping. Role-based names beat hue-based names: color-text and color-surface survive a rebrand, while color-blue and color-lightgray stop meaning anything the day the palette changes.

The other naming habit is deciding what a token name does not contain. A name should not encode a value, a screen size, or a device. The size for large screens belongs to the alias layer, not to the name font-size-desktop-16, because the decision about which screens get which size will change more often than the raw size does.

A token name is also documentation. Write the reason for each alias down once, next to the value or in the DESIGN.md export. Six months later someone on the team will ask why color-brand-primary points where it does, and a sentence of intent beats reverse-engineering the choice from the raw value.

Tokens in Version Control

Generated token files belong in the repository next to the code that consumes them, committed and reviewed like any other source file. A pull request that changes color-brand-primary from one value to another is readable by a reviewer in a way that the same change buried in a component diff is not. Treat the generated files as generated: edit the brand kit, regenerate, and review the diff, but do not hand-patch a token file and expect the next export to keep the change.

When Tokens Are Overkill

A token pipeline is overhead until there is something to coordinate. A single static site with one stylesheet does not need a W3C JSON file and a Tailwind theme; CSS variables in one file are enough, and the brand kit can still produce them. The formats earn their keep when the same decisions must land in several places: a web app, a marketing site, a native client, and a design tool. If a value change currently requires editing one file, add tokens when it starts requiring three.

Questions That Come Up

Where do component tokens live in the brand kit? The kit covers the shared layer, fonts, colors, and scale. Component-scoped names such as button-background are aliases that point into that shared layer, and they belong in the consuming project's own token file so a component can change without touching the brand source.

Does the exporter write files for me? No, it generates the text in the browser and you copy it into your project. Nothing is written to disk and nothing leaves the page, which keeps the tool safe to use with proprietary brand values.

Does the Tailwind export work with version 4? The generated theme object targets the config-based setup. Tailwind v4 moved configuration into CSS-first directives, so you adapt the same values into the new structure once; the JSON and CSS exports carry over unchanged.

Can I import exported tokens back into a tool later? The JSON export is a handoff format, not a round-trip file. To reconstruct a kit, paste the values into the brand kit's custom color and scale fields, but treat the exporter as one way.

Do the tokens cover spacing and radii too? The brand kit exports the typography and color layers. Spacing, shape, and shadow tokens follow the same three-layer naming pattern, so you can add them to the same token file with the same conventions when the system grows.

Related Tools

The brand kit builder exports the six formats described above. The typography playground lets you test the type scale before you export. The color palette tool generates the color tokens you import into the brand kit.