Published October 12, 2026
The middle value of clamp() is just the equation of a line. You pick two endpoints: how big the text is at your smallest screen, and how big at your largest. The preferred value is the straight line between them. Once you see the arithmetic worked through once, you'll never guess at these numbers again.
Take a concrete case. Body text should be 16px on a 320px phone and 24px on a 1200px desktop. Those are your two points: (320, 16) and (1200, 24). Step one, the slope: (24 - 16) / (1200 - 320) = 8 / 880 = 0.00909. Multiply by 100 to express it as a viewport percentage and you get 0.909vw. Step two, the intercept: 16 - (0.00909 x 320) = 16 - 2.909 = 13.09px. Convert to rem for the bounds and the intercept, because rem respects the reader's font-size setting: 13.09px is 0.818rem, 16px is 1rem, 24px is 1.5rem. The result:
font-size: clamp(1rem, 0.818rem + 0.909vw, 1.5rem);The one check that catches arithmetic slips
Plug your endpoints back in and the preferred value must return exactly the min and max. At a 320px viewport: 0.909vw is 0.00909 x 320 = 2.909px, plus the 13.09px intercept gives 16px. The min. At 1200px: 0.909vw is 10.909px, plus 13.09px gives 24px. The max. If either endpoint comes back wrong, the slope or intercept is off, and the text will drift between sizes in ways you won't notice until someone checks on a tablet. This thirty-second check is the whole quality control step. Everything between the endpoints takes care of itself, because that's what a line does.
Two places this formula goes wrong in practice. First, unit mixing: if the bounds are in rem, the intercept has to be in rem too, and the slope stays unitless-to-vw. Mixing px bounds with a rem intercept is the most common way a hand-calculated clamp quietly misbehaves. Second, a negative intercept. It happens with steep slopes on narrow ranges, and it's not fatal, since the min cap catches it, but a negative rem offset usually means the range is wider than the type needs. And one hard rule from the accessibility side: never let the preferred value be a bare viewport unit with no rem term. Text sized in pure vw ignores browser zoom, and WCAG expects text to survive 200% zoom. The rem intercept is what keeps fluid text zoomable.
The honest footnote: nobody does this by hand twice. You work it through once so you trust the math, then you let a generator handle the arithmetic from here on. The endpoint check is the part worth keeping in your head.
Frequently asked questions
What is the formula for the clamp() preferred value?
Slope = (max size - min size) / (max viewport - min viewport). Intercept = min size - (slope x min viewport). Preferred = intercept (in rem) + (slope x 100)vw. Plug the endpoints back in to verify: the preferred value must equal the min at the min viewport and the max at the max viewport.
Can I use px instead of rem in clamp()?
You can, but rem is the better habit for the bounds and the intercept. Rem respects the reader's browser font-size setting and browser zoom, which keeps fluid type accessible.
My intercept came out negative. Is the formula broken?
No. A negative intercept just means the slope is steep relative to the range. The min cap in clamp() handles it. But it's often a sign the size range is wider than the type really needs.
Why does my fluid text stop growing on large screens?
Either the max bound is doing its job, or the preferred-value math is off. Run the endpoint check: at the max viewport the preferred value should equal the max size. If it overshoots, the slope is too steep.
Can the preferred value be a plain vw number with no rem?
Technically yes, but don't do it for text. A bare vw value doesn't grow when the user zooms, which fails WCAG's 200% resize expectation. The rem term is what keeps the type zoomable.
Generate a fluid clamp() value in seconds.