Component Tokens

Component tokens are the last link in the chain that turns a modular type scale into a living system. They take your raw sizes generated from a single base and ratio and your semantic roles like h1 body and caption and attach them to actual component parts. This means the title inside a feature card gets its own token called feature-card-title-size. That token points to the semantic h2 role. The semantic role points to the raw size produced by multiplying the base by the ratio three times. The whole chain stays connected. Change the base from 16 to 17 for older audiences and the card title updates automatically along with every other piece of text in the product. This layer gives you the ability to make context specific adjustments to weight tracking or leading without ever leaving the system. It is the difference between a scale that lives in a Figma file and a scale that survives four quarters of shipping. The previous article showed raw and semantic layers. The component layer completes the picture and stops the system from fracturing the moment real product requirements appear.

Component tokens are not semantic tokens. Semantic tokens define the roles that carry meaning across the product. Component tokens consume those roles and apply them inside specific patterns. They are not raw tokens either. Raw tokens are the naked rem values like 1.9375rem. Component tokens never hold naked values. They are not a blank check for designers to create special snowflake sizes for every new campaign. The governance rules in the modular type scale article exist for a reason. Exceptions get a name and a date. Component tokens are how you name those exceptions inside the system instead of outside it. They stop the slow slide into the font size graveyard where 47 unexplainable values fight for dominance. They are not permission to skip the hard work of refining your semantic names until they fit the product.

Concrete example. Extend the JSON example from the modular type scale article with a component section. The file now includes a component object with entries like card-title-size set to reference the semantic h3 value button-primary-label-size set to reference the semantic body value with an added weight modifier and table-cell-value set to reference semantic small with tabular numbers forced on. In 2022 Stripe's design team did exactly this for their checkout flow. The payment summary card used a component token for summary-total that referenced semantic lead but forced a tabular numbers font variant so the digits aligned perfectly. When they updated their ratio from 1.25 to 1.2 for a denser feel in the admin view the totals stayed aligned because the component token chain remained intact. Material Design 3 uses hundreds of these. Their bottom-sheet-title component token references the semantic headline-medium but applies a specific tracking value that only makes sense inside bottom sheets. Apple's Human Interface Guidelines do the equivalent with SwiftUI modifiers where navigation bar titles use a component level token that maps back to the system scale yet carries different leading for compact mode. Linear the issue tracking tool built their entire UI on component tokens that sit on top of a 1.2 ratio scale. Their command-bar-text-size token references semantic small but adds a specific font feature setting for tabular numbers. Vercel in 2023 used component tokens for sidebar-nav-item that referenced semantic text-ui with a tighter letter spacing value that never leaked to body copy. These real world systems show that component tokens are what let you stop repeating yourself across Figma and code while the single ratio stays sacred.

Use component tokens when your product has matured past the prototype phase and the component library has more than a dozen patterns that repeat. They are perfect for situations where the semantic token is too generic for the context like when your page h2 needs to be loud but the same semantic size inside an empty state card needs to sit quieter. They pair perfectly with the quarterly review process. During the review you examine which component tokens are pulling their weight and which have become dead weight. Fold unused ones back into semantic. Never introduce component tokens before the raw and semantic layers are stable. Do not use them on one off marketing pages that change every month. They add maintenance cost. A small team without a dedicated design systems engineer will drown in them. Use them only when the payoff in consistency and speed outweighs the added complexity. That moment usually arrives around the time your exception list from the governance rules grows longer than 10 items. Fix the semantic layer first then add the component layer on top.

Component tokens let you bend the rules of your modular type scale without ever breaking them.