Posted February 11th 2026.
Written by Kristian Hansen.
1. The challenge: multiple fonts, multiple styles
If you’re not using responsive text styles in Figma (article coming) and are designing for multiple screen widths, chances are you have a lot of text styles. Even if you do use responsive text styles, but work with a very flexible system, you might still have a lot.
Usually, I work with Caption, Body, Heading, and Display text styles. Previously, each of these was split into sm, md, and lg interpolation points. That is a lot of styles.
The problem is that font weights are named differently across font families:
Regular → Book
SemiBold → Semi-bold
Medium → Text
If weights are hardcoded or aliased flatly, swapping a font family often breaks the mapping across all related styles.
A minimal nested token example
Here is the simplest version of what I used:
font.fontFamily.primary = Inter
font.fontWeight.primary.strong = Semi Bold
font.fontFamily.secondary = Moderat
font.fontWeight.secondary.strong = Bold
font.fontFamily.display = primary
Text styles then resolve relationally:
DisplayMd
Font: {font.fontFamily.{font.fontFamily.display}}
Weight: {font.fontWeight.{font.fontFamily.display}.strong}
Now, changing:
font.fontFamily.display = secondary
…automatically swaps both the font family and the correct corresponding weight across all Display styles.
Why this is satisfying in practice
Want to quickly see how all body or display styles look with the secondary font family?
This setup makes that extremely satisfying and easy.
In themable systems, the number of text styles grows fast. That is where relational tokens start to matter and provide value.
Instead of swapping individual values, you are swapping relationships. That is the core of scalable design systems.
When nested tokens make sense
Admittedly, in most cases, this is probably overkill. Nested tokens are currently an unsupported feature of Token Studio. They require the right kind of themable product to make sense.
For example, if a product is white-label or supports multiple brands, typography may need to be swapped consistently across themes. The same applies to products with flexible typography across breakpoints. In these cases, nested tokens reduce duplication, preserve semantic intent, and make iteration far faster.
Takeaways
Nested tokens are not just a clever syntax trick. They are about:
Modeling domain relationships explicitly
Avoiding accidental coupling
Designing for configurability
Treating tokens as a data model, not just a list of values
The real joy comes when you see a small change cascade across dozens of styles without touching a single hardcoded value.
Have you worked with nested tokens beyond typography? I’d love to hear how others approach this… hit me up on LinkedIn!
