22/4/2026 · 6 min read
For years, responsive typography meant one font size on mobile and a different one on desktop, toggled by a media query. The result was type that jumped rather than scaled — readable in two states, awkward in everything between. CSS clamp() solves this cleanly. One declaration, no breakpoints, type that scales linearly across any viewport width you choose.
This guide covers the mechanics of clamp(), a reliable formula for deriving the preferred value, practical examples for headings and body text, and the accessibility considerations that most tutorials skip.
clamp(min, preferred, max) takes three values. The result is always within the range defined by min and max, with the preferred value applied as long as it stays in that range. For font sizes, you typically write something like font-size: clamp(1rem, 2.5vw, 1.5rem). On a narrow viewport the preferred value falls below 1rem, so clamp returns 1rem. On a wide viewport the preferred value exceeds 1.5rem, so clamp returns 1.5rem. In between, the size scales linearly with viewport width.
The three values map directly to your design decisions: the minimum is the smallest size you'd ever want to show (usually your mobile size), the maximum is the largest (your desktop size), and the preferred is the growth rate — how fast the size scales between those two extremes. Setting the preferred value correctly is where most people get lost.
The preferred value is a linear interpolation between your min size at a minimum viewport width and your max size at a maximum viewport width. The formula is: preferred = min-size + (max-size - min-size) * ((100vw - min-vw) / (max-vw - min-vw)). Simplified, this becomes a vw value with a rem offset that ensures it hits your exact min and max values at your chosen breakpoints.
A worked example: you want a heading that's 24px at 320px viewport and 48px at 1200px. The slope is (48 - 24) / (1200 - 320) = 0.02727. Converted to vw: 2.727vw. The intercept (ensuring the line passes through the right points) works out to about 15.27px. So your clamp becomes: clamp(1.5rem, 0.955rem + 2.727vw, 3rem). You can also use one of the many clamp calculators online to do this arithmetic for you — what matters is understanding what the three values represent so you can audit the output.
Once you've derived the preferred value for each step in your type scale, you can store it as a CSS custom property: --text-2xl: clamp(1.5rem, 0.955rem + 2.727vw, 3rem);. Reference it everywhere you need that size. If the design changes, you update one value.
For display headings — the largest type on a page — the range is wide and the fluid scaling is most visible. A hero heading might go from 36px on mobile to 80px on a large desktop. The jump at a single breakpoint would be jarring; fluid scaling makes it feel intentional. Apply clamp(2.25rem, 1rem + 4vw, 5rem) and the heading grows naturally as the viewport expands.
For body text the story is different. Reading comfort depends on line length, and line length changes with layout more than with viewport width. In a single-column layout, body text at 16px on mobile and 18px on desktop is usually sufficient — a narrow clamp range is fine. In multi-column layouts at large viewports, the column width is already constrained, so the font size often doesn't need to scale at all. Know what your layout is doing before you apply clamp to body text, or you'll solve the wrong problem.
For UI labels, captions, and code blocks, clamp is often unnecessary. These elements have hard legibility floors — a label smaller than 12px is inaccessible regardless of viewport — and the visual difference between mobile and desktop is not worth the added complexity. Use fixed sizes here and save clamp for the elements where fluid scaling genuinely improves the reading experience.
The same technique applies to spacing. Section padding, gap values, and margin between typographic elements can all be expressed as clamp() values, creating a layout that breathes consistently at every viewport size rather than cramping on mobile and stretching on desktop. This is particularly useful for hero sections and editorial layouts where the relationship between type and surrounding space is part of the design.
The principle is the same: define a minimum spacing at your smallest viewport, a maximum at your largest, derive the preferred slope, and write one declaration. The visual result is a layout that feels hand-tuned at every width — because it effectively is, continuously, by the browser.
The most commonly overlooked issue with clamp() is how it interacts with user font size preferences. When a user sets their browser's default font size to 20px (common for low-vision users), a clamp() value expressed in rem for the min and max will scale correctly — but a preferred value expressed purely in vw will not, because vw is not relative to the user's font size preference.
This is why the preferred value should always include a rem component alongside the vw component, as in the formula above. The rem intercept ensures that a user who has increased their browser font size gets a proportionally larger result, not just the viewport-width-scaled value. Pure vw preferred values are an accessibility failure waiting to happen.
Test with browser zoom at 200% and with the default font size set to 20px. If your type still reads comfortably and your layout doesn't break, you've implemented fluid typography correctly. If it collapses, review your preferred values and ensure the rem component is present.
Once you have a fluid type scale stored as custom properties, adding a new design system token takes thirty seconds. Adjusting the scale at a stakeholder review takes seconds more. The underlying formula is not complex; the discipline is simply understanding what the three values represent and deriving them deliberately rather than guessing.
Start with your headings. Define the min and max sizes from your existing design, pick your target viewports, run the formula. Replace your current heading sizes. Verify the output in the browser at several viewport widths. If it looks right, you're done — and you've deleted two or three media queries in the process.
