Design Tokens: From Concept To Native Tooling
Design tokens have long been the conceptual bridge between design decisions and production code. They provide a structured way to capture the variables behind an interface — colors, typography, spacing, fills, borders, and shadows — as a single source of truth that both designers and engineers can reference. The idea has gained traction alongside the growth of design systems, where scaling across products and environments demands that values remain agnostic of their eventual application.
Beyond maintainability, tokens are a practical tool for theming. Because design decisions stay decoupled from their values, swapping entire visual identities becomes a matter of switching token sets. That covers everything from straightforward light and dark modes to multi-brand systems and user-customizable interfaces.
Why Tokens Have Been Hard To Implement
Despite their usefulness, tokens have historically lacked a standardized format. Every design tool and frontend framework has implemented the concept in its own way, and keeping design files in sync with code typically meant relying on third-party plugins with fragile synchronization. The result was a gap between the theory of tokens and the reality of team workflows.
The W3C has been working to close that gap through its dedicated Design Tokens Community Group, which is developing an open standard for how products and design tools handle tokens. Widespread adoption of that standard will make cross-tool and cross-team token workflows far more predictable. Penpot is the first design tool to implement tokens natively according to that emerging W3C specification, and it exposes them through an API that serves values in the official standardized format — no plugin required.
Planning A Token Structure
Putting tokens to work in a real interface starts with structure. Consider a login screen built from components — buttons, inputs, and text layers arranged into Flex layouts. Before defining any tokens, it helps to map out the hierarchy you will need. A design already in place makes it easier to plan that structure against actual usage.
Tokens in Penpot are organized into sets, which you can nest by including slashes in their names. A first set called primitives is a good place for literal values — colors like slate.1 or slate.10. These are the raw materials that everything else will reference.
Naming is where tokens succeed or fail. A set named primitives stores literal values, but applying those values directly across a theme can quickly become unmanageable. The same shade of grey might serve as a border, a background, or text. Keeping those definitions independent means introducing a second abstraction layer — a semantic one.
That semantic layer, such as a set called globals, references the primitives rather than containing literal values directly. Token names like text.muted or background.primary describe intent, not appearance. Names such as text.dark or background.blue would break down the moment you need to switch between modes and brands, because they couple the token to a fixed value.
Building Sets And Themes
With primitives in place, you can start handling multiple modes. Splitting the primitive values into separate sets — for example, light and dark — each containing tokens with identical names but different values, gives you a foundation for switching appearance. Tokens in Penpot can reference other tokens by wrapping their names in curly brackets. When the light set is active, a token pointing at slate.1 resolves to a dark value; activating the dark set instead resolves it to a light value.
Multiple sets can be active at once, even when they define the same token names. In that case, the set lowest on the list overrides the values defined above it — the same specificity behavior you get when redeclaring a variable in code or overriding a property in CSS.
Manual set toggling works for testing, but Themes make the system practical. A theme bundles sets into functional choices: a theme named light under a group called Mode would select the light set for values plus the globals set for styling. Switching themes from a single dropdown then updates the entire interface without touching individual layers.
Scaling To Brands And Combinations
Two abstraction layers handle mode switching, but real systems often need more. Adding brand theming alongside light and dark modes means extending the hierarchy rather than complicating it.
Create another group — Brand, for instance — with option sets named Slate, Indigo, and Purple, each containing its own primitive values. The globals set then references those brand sets instead of the mode-specific primitives. This keeps the two concerns orthogonal: the brand determines the color family, while the mode determines the shade within that family.
With that structure in place, every combination becomes testable. Switch the brand to change the accent colors, switch the mode to flip between light and dark, and the full interface responds accordingly — without ever redesigning the screen by hand.
Beyond Colors: Tokens for the Whole System
Colors are just one token type in Penpot. The same mechanism can hold spacing, sizing, layout, and other design values. The team plans to broaden the available token types over time, all following the upcoming design tokens standard.
Penpot’s native token approach does more than simplify workflows — it also makes tokens more capable. Tokens already support math operations through the CSS-like calc() function, so you can add, subtract, multiply, or otherwise combine token values directly.
Moving tokens from the design file into code is already possible: you can export them as JSON. Soon, an API will let you import tokens straight into your codebase. Penpot's roadmap also includes support for gradients and composite tokens, which store multiple values, making the system even more flexible.
To stay up to date on these developments, you can follow Penpot on LinkedIn, BlueSky, or their site. If you want to inspect the example file before building your own, you can duplicate it here.
For deeper reading, these resources are worth a look:
- Design Token Overview, Penpot website
- What are design tokens? A complete guide, Penpot Blog
- Design Tokens, Penpot Docs
- Design tokens format module, W3C Community Group Draft Report
Why Native Tokens Matter
Penpot’s move to native design tokens is a meaningful step toward closing the gap between design and code. Organized, well-documented variables are useful, but doing this in a scalable, maintainable way grounded in open standards goes further. It makes adoption realistic for real teams.
The practical upside is clear: better maintainability, fewer handoff hiccups, and smoother communication across designers and engineers. If your goal is a more structured design system without sacrificing collaboration, Penpot’s token support is worth evaluating.
