How to convert Figma font sizes to CSS clamp tokens

Most type scales start as fixed values in Figma. That is not a mistake. A design file needs concrete numbers so designers can compare hierarchy, rhythm, and density. The mistake happens later, when those fixed numbers are copied into CSS as if every screen were the same width.

A reliable responsive typography workflow starts with one question: at which viewport should the design be exact? If your desktop frame is 1440px wide and the h1 is 72px there, the final CSS should still resolve to 72px at 1440px. Mobile and large desktop behavior should scale around that anchor instead of replacing it.

That design viewport is the handoff contract. It lets designers keep their exact frame values, while developers can still ship fluid typography. The TYPECLAMP generator is built around that contract: enter the design value, choose the viewport range, then inspect whether the responsive token still lands on the original value.

• Mobile viewport: the smallest width you want to support, for example 375px.
• Design viewport: the Figma frame where the fixed values should stay exact, for example 1440px.
• Maximum viewport: the width where type should stop growing, for example 1920px.
• Design font size: the actual Figma value for each style, for example display-lg = 72px.

CSS clamp combines three parts: a minimum value, a preferred fluid value, and a maximum value. The browser uses the fluid value while it stays between the minimum and maximum. Once the fluid value gets too small or too large, the browser uses the boundary instead.

For example, imagine a display heading that is 72px in a 1440px Figma frame. You want it to scale down toward mobile, but not below 40px. You also want it to grow slightly on wide screens, but stop at 84px. The final output should be a reusable token, not a one-off declaration hidden in a hero component.

The important detail is that the preferred value must be calculated from real viewport anchors. A clamp expression can look convincing and still miss the design size. Treat the design viewport as a test case: when the viewport equals 1440px, the computed value should equal the Figma value.

:root {
  --font-display: clamp(2.5rem, 1.544rem + 4.082vw, 5.25rem);
}

.hero-title {
  font-size: var(--font-display);
}

The useful output is not only the clamp expression. The useful output is a named token. Tokens make the type scale portable across components, pages, and future redesigns. If every component owns its own responsive font-size, the system becomes hard to audit.

A small landing page might only need h1, h2, body, label, and caption. A larger product might need display, heading, body, label, code, and numeric styles. The exact names are less important than the fact that designers and developers use the same names.

Once the tokens exist in CSS, they can be mapped into Tailwind, SCSS, component styles, or a broader design token pipeline. The token name becomes the shared language; the clamp expression becomes the implementation detail. For naming strategy, see the companion guide on typography tokens for design systems.

:root {
  --type-display-lg: clamp(2.5rem, 1.544rem + 4.082vw, 5.25rem);
  --type-heading-md: clamp(1.75rem, 1.272rem + 2.041vw, 3.125rem);
  --type-body-md: clamp(1rem, 0.957rem + 0.184vw, 1.125rem);
  --type-label-sm: clamp(0.75rem, 0.728rem + 0.092vw, 0.8125rem);
}

A good type handoff should not stop at plain CSS. Developers increasingly consume typography as tokens, and different teams need different package shapes. A marketing site might want CSS custom properties. A product app might want Tailwind theme values. A design system might need JSON tokens that can feed multiple platforms.

For Tailwind v4, the natural target is CSS-first theme variables using @theme. For multi-platform token pipelines, Style Dictionary can transform token JSON into platform-specific outputs. If your team wants the values back in Figma, the Figma Variables API is the direction to watch.

The export format should preserve the important metadata: token name, clamp value, design size, design viewport, min and max bounds, line-height, weight, and unit choices. Without that context, a responsive token becomes harder to review later.

• CSS custom properties for vanilla CSS, component CSS, and quick implementation.
• Tailwind v4 theme variables for utility-first teams.
• SCSS maps for projects that still compile design values through Sass.
• Style Dictionary or JSON tokens for design system pipelines.
• Figma variable exports when designers need the generated values back in the design file.

@import "tailwindcss";

@theme {
  --text-display-lg: clamp(2.5rem, 1.544rem + 4.082vw, 5.25rem);
  --text-display-lg--line-height: 1.05;
  --text-display-lg--font-weight: 650;
}

The most important quality check is simple: does the generated value match the Figma value at the design viewport? If the answer is no, the responsive formula may look fluid, but it is not respecting the design source.

For a design system, this check should happen for every major type style. Headings usually show mistakes first because they change dramatically across viewports, but body text and labels also matter. Small mismatches accumulate across dense interfaces.

TYPECLAMP is built around that exact check. You enter the fixed design values, choose the design viewport, and preview the result at mobile, design, and large desktop widths. The base design size stays the reference point instead of becoming a suggestion. The scale map and per-token waveform make the behavior visible before you copy the CSS.

• At mobile width, the type should be readable and not wrap awkwardly.
• At the design viewport, the type should match the Figma size exactly.
• At wide desktop, the type should feel intentional and stop before it becomes oversized.

The first common mistake is using viewport units without limits. A value like 5vw can look fine at one screen width and ridiculous at another. Clamp exists because responsive typography needs boundaries.

The second mistake is making every text style fluid. Not every label, button, caption, or table value needs to scale. Fluid type is usually most useful for display headings, article titles, marketing pages, and systems where hierarchy needs to breathe across viewports.

The third mistake is ignoring line-height. A font-size can scale correctly while the line-height still breaks the layout. Large headings often need tighter line-height on desktop and careful checks on mobile once they wrap. For a deeper look, read why line-height is harder on the web than it looks.

• Do not use raw viewport units as a complete typography system.
• Do not set mobile and desktop sizes by eye if the design system needs repeatable values.
• Do not forget max values for wide screens.
• Do not treat line-height as an afterthought.

A simple workflow is enough for most teams. First, copy the font sizes from the Figma type styles. Second, set the mobile, design, and maximum viewports. Third, preview the scale and adjust min/max behavior until the system feels right. Fourth, export the generated tokens in the format your project actually uses.

The result is not a theoretical fluid scale. It is a practical handoff from fixed design values to responsive production CSS. That is the important distinction: the design remains the source of truth, but the implementation is allowed to behave like the web.

If you are starting from a Figma file, begin with the largest headings and body text. Those two ends of the scale reveal most problems. Once they work, fill in the intermediate heading, label, and caption tokens. Then compare the whole system in the overview chart instead of reviewing each token in isolation.

For the broader rules behind fluid type, the next useful read is responsive typography with CSS clamp. When you are ready to generate values, open the TYPECLAMP generator and start with one display token.

/* 1. Define tokens once */
:root {
  --type-h1: clamp(2.5rem, 1.544rem + 4.082vw, 5.25rem);
  --type-body: clamp(1rem, 0.957rem + 0.184vw, 1.125rem);
}

/* 2. Reuse them across components */
.article-title {
  font-size: var(--type-h1);
}

.article-body {
  font-size: var(--type-body);
}