9 min read
Responsive typography with CSS clamp: rules that hold up
Use CSS clamp for fluid typography without creating unreadable mobile text, oversized desktop headings, or impossible design system values.
Use clamp when type should respond to layout
CSS clamp is useful because web typography rarely has one correct size. A hero headline may need to feel compact on a phone, match an exact Figma value on desktop, and stop growing before it becomes theatrical on a wide monitor. Clamp lets one declaration cover that range.
That does not mean every text style should be fluid. Small interface labels, dense navigation, table cells, and form helper text often work better with stable sizes. Fluid type is strongest when the text is part of layout rhythm: display headlines, article titles, landing page sections, editorial intros, and major product page headings.
A good rule is simple: if the type’s visual role changes with the viewport, clamp is probably useful. If the text is part of dense UI chrome, it probably needs stability more than fluidity.
- Use clamp for display text, marketing headings, editorial titles, and large section headings.
- Be careful with clamp for buttons, tabs, table cells, labels, and small navigation.
- Keep body text mostly stable unless the layout has a strong editorial reason to scale it.
- Treat every fluid token as a design decision, not a default.
Understand the three parts
A clamp expression has three values: minimum, preferred, and maximum. The minimum protects small screens. The preferred value is usually a calculated expression that changes with viewport width. The maximum protects large screens.
The middle value is the part people tend to overthink, but the boundaries are what make the token usable. Without the minimum, headings can become unreadable on mobile. Without the maximum, large screens can make typography feel inflated and disconnected from the rest of the layout.
In practice, every responsive type token should answer three questions before it is shipped: how small may this get, where should it match the design, and where should it stop growing?
.hero-title {
font-size: clamp(
2.5rem, /* minimum: 40px */
1.544rem + 4.082vw, /* preferred: fluid value */
5.25rem /* maximum: 84px */
);
}Do not use raw viewport units as typography
Viewport units are not wrong, but they are incomplete on their own. A font-size like 5vw will keep reacting to the viewport forever. It does not know when the text has become too small, too large, or visually out of proportion with the rest of the interface.
Clamp turns viewport scaling into a controlled range. The browser can still interpolate between sizes, but the designer and developer define the boundaries. That is the difference between fluid typography and typography that merely changes.
If you already have fixed values in Figma, start from those values instead of inventing a viewport unit by eye. The article How to convert Figma font sizes to CSS clamp tokens covers that workflow in more detail.
/* Too loose: no boundaries */
.hero-title {
font-size: 5vw;
}
/* Better: fluid, but controlled */
.hero-title {
font-size: clamp(2.5rem, 1.544rem + 4.082vw, 5.25rem);
}Keep the design breakpoint sacred
For product work, the design viewport is the anchor. If a desktop Figma frame says the heading is 64px at 1440px, the clamp token should resolve to 64px at 1440px. Otherwise the generated value may be fluid, but it is no longer faithful to the design.
This is especially important for design systems. A single heading being 2px off may not seem serious, but a whole scale drifting away from Figma creates trust problems. Designers see one hierarchy, developers ship another, and nobody knows which one is the source of truth.
TYPECLAMP is built around this idea: set the design viewport, enter the fixed design value, and generate a responsive token that still matches the design at that viewport.
- Mobile width checks readability and wrapping.
- Design width checks fidelity to Figma.
- Wide desktop checks whether the maximum value is restrained enough.
Preview the whole scale together
A clamp value can look correct in isolation and still fail as part of a type system. The gap between h1 and h2 might collapse on mobile. Body text might feel stable while headings move too aggressively. Captions might become visually disconnected from everything else.
The useful test is to preview the system together at several widths. Look at hierarchy, not just math. If every token technically scales but the page feels less coherent, the ratio or min/max choices need to change.
Line-height needs the same treatment. A font-size token can be technically correct while the line-height breaks once a heading wraps. The next related topic is why line-height is harder on the web than it looks.
- Check the largest heading and body text first.
- Then check intermediate headings for hierarchy gaps.
- Preview long words and multi-line headings, not only perfect marketing copy.
- Review line-height at mobile widths where wrapping changes most.
Use tokens so the rules survive implementation
The goal is not to paste clamp formulas into random components. The goal is to create tokens that carry the rules into implementation. Once a token is named, the formula becomes reusable and easier to review.
A token also makes future changes safer. If a heading needs a different maximum value, the team can adjust one variable instead of searching through components. If a design system grows, the same naming pattern can be extended.
This is where clamp becomes practical. It is not just a clever CSS function; it is a way to express responsive typography decisions in code.
:root {
--type-display: clamp(2.75rem, 1.663rem + 4.638vw, 5.875rem);
--type-heading: clamp(2rem, 1.478rem + 2.226vw, 3.5rem);
--type-body: clamp(1rem, 0.957rem + 0.184vw, 1.125rem);
}
.page-title {
font-size: var(--type-display);
}
.section-title {
font-size: var(--type-heading);
}Practical rules that hold up
The best responsive typography systems are boring in the right places. They use fluid sizing where layout and hierarchy benefit from it, and stable sizing where interface density matters more. They have explicit minimums and maximums. They preserve the design breakpoint. They are previewed as a system, not as separate formulas.
If you are unsure where to start, make only your largest two or three heading styles fluid. Keep body and UI labels conservative. Then test across mobile, design, and wide desktop widths. Once that feels right, expand the system only where the extra fluidity improves the page.
When you are ready to create real values, open the TYPECLAMP generator, load a preset, and adjust the viewport settings to match your design file.
- Use fewer fluid tokens than you think at first.
- Set maximum values deliberately, especially for large displays.
- Match the Figma value at the design viewport.
- Document the viewport assumptions next to the tokens.
- Review line-height and wrapping before shipping.