Native open-standard tokens in Penpot (Tokens Studio × Penpot)

Penpot and Tokens Studio collaborated to ship native design tokens inside Penpot using the W3C DTCG format — not a one-off proprietary variable blob, not a retro-fit on top of CSS variables, but tokens-as-they-appear-in-the-spec, stored and exchanged in canonical JSON. Penpot is the first open-source design tool to fully embrace DTCG; Tokens Studio brings the integration patterns it built across other tooling. The combination matters because design systems work — tokens authored once, used everywhere — finally has an end-to-end open path.

This is why the collaboration between Penpot and Tokens Studio marks such an important milestone. Together, we've introduced native, open-standard design tokens into Penpot, making it the first open-source design tool to fully embrace the W3C Design Tokens Community Group (DTCG) specification.

TL;DR

• Native tokens in Penpot, stored as DTCG-compliant JSON.
• Token sets for organizing primitives, semantics, and component-level tokens.
• Themes that compose token sets — light/dark, brand, accessibility variants.
• Theme switching without duplicating libraries.
• Open standards all the way down — the same JSON your code pipeline already speaks.

What "native" actually means

Lots of design tools have a "variables" feature. The catch has historically been that each tool stores them in a proprietary format, with import/export bridges that drop fidelity. "Native DTCG" means:

• The internal storage is the spec format.
• Import and export are the same operation — write the JSON, hand it to another tool.
• The semantic types (color, dimension, typography, shadow) match the spec.
• Aliases and references resolve the way the spec says they resolve.

Penpot is the first design tool to ship that end-to-end. The pragmatic effect: a token authored in Penpot can flow directly into Style Dictionary, into a Tailwind @theme block, into iOS Swift constants, without any tool-specific conversion.

Token sets

Token sets are the organizational unit. A typical project might have:

• Primitives — color.blue.500, spacing.4, font.size.16. Not for direct use; the raw values.
• Semantics — color.surface.elevated, spacing.card-padding, font.size.body. References to primitives.
• Components — button.background, field.border. References to semantics.
• Brand-specific overlays — acme.color.primary, zenith.color.primary.

Each set is a standalone DTCG file. Designers work in the set that matches the layer of abstraction they're touching; engineers consume the merged result.

Themes

Themes are selections of token sets, not duplicates:

default: [primitives, semantics, components]
dark:    [primitives, semantics-dark, components]
acme:    [primitives, semantics, components, acme-overlay]

Switching themes in Penpot re-resolves the token graph against the new selection. No copy-paste, no parallel libraries.

Theme switching, in practice

Designers see this as a one-click toggle in Penpot — switch from "default" to "dark" and the entire mockup re-renders. Behind the scenes:

• The active token set list changes.
• All references re-resolve.
• Components that were drawn with semantic tokens (color.surface.elevated) pick up the new value.
• Components that hardcoded a primitive (color.gray.500) don't change.

That last point is the design discipline DTCG enables: design at the semantic layer, not the primitive layer, and theme switching becomes free.

Why this matters for engineering

What makes this different from every other "variables" feature is the commitment to open standards. Tokens in Penpot are stored and exchanged using the W3C DTCG spec, which means they can move seamlessly across tools, libraries, and pipelines without being locked into a proprietary ecosystem.

The engineering side of the workflow gets simpler:

• No proprietary export step. The Penpot file already contains DTCG JSON.
• One pipeline. Style Dictionary (or your tool of choice) consumes the JSON and emits CSS / Swift / Android / Flutter.
• Round-tripping — engineers can edit a token in code, hand the JSON back, and Penpot reads it without information loss.
• PRs are reviewable. A token change is a JSON diff, not an opaque binary blob.

Pair this with the Style Dictionary 5.4 release and you have the most popular code-generation tool aligned with the same spec on the same release cadence. The ecosystem moves together.

Why open-source matters here

The open-source angle is more than ideology. Three concrete benefits:

• No vendor lock-in. If Penpot's roadmap drifts, your tokens are still standard DTCG JSON; you can move them to another DTCG-aware tool without conversion.
• Self-hosting. Teams that need to keep design assets on their own infrastructure (regulated industries, government, security-sensitive products) can run Penpot themselves.
• Community contributions. Bug fixes and feature requests can land directly upstream rather than waiting for a vendor's roadmap.

For internal tooling teams that have wanted to standardize on DTCG but couldn't get a closed-source vendor to commit to the spec, this is the moment.

Adoption pattern

If you're considering moving a design system to Penpot + Tokens Studio:

1. Export your existing tokens from whatever tool currently holds them — Figma variables, a hand-maintained Style Dictionary file, etc. Most tools have a DTCG export by 2026. 2. Import into Penpot — the JSON is read as-is. 3. Reorganize into token sets — primitives, semantics, components — if the export came in flat. 4. Define themes by composing sets. 5. Wire the pipeline — Style Dictionary builds platform output from the same JSON Penpot reads. 6. Migrate components to reference semantic tokens, not primitives, so theme switching works.

Where this connects

The DTCG 2025.10 stable post covers the spec itself; the Style Dictionary 5.4 post covers the most-used code generator. With Penpot in the design tool, you have an open-source path from design to production.

References

• Tokens Studio + Penpot announcement: tokens.studio/blog
• Penpot: Design tokens collaboration hub
• W3C Design Tokens Community Group: github.com/design-tokens/community-group

Source / further reading: Tokens Studio blog