Published October 13, 2026
Is your CSS clamp font size not scaling? Nine times out of ten the line below is the fix. Your middle value is too aggressive, so the browser slams into the maximum on a phone and the text never visibly moves. Swap the 10vw for something in the 2 to 4vw range and watch the scaling come back to life.
/* broken: hits 32px almost immediately */
h1 { font-size: clamp(16px, 10vw, 32px); }
/* fixed: actually scales between the limits */
h1 { font-size: clamp(20px, 2.5vw + 1rem, 48px); }If that solved it, you are done. If your clamp() is still misbehaving, one of the other five usual suspects is probably guilty. They are all worth knowing because clamp() fails silently: it never throws an error, it just sits there looking like a fixed value.
1. The viewport value reaches the max too early
This is the one from the fix above, and it deserves the detail. At 10vw, a 400-pixel phone computes 40px before the clamp even gets a vote, so the result pins to your 32px maximum on every screen that matters. The clamp is technically working. It is working so well you never see it work. The preferred value should cross through the middle of your range at the viewports you care about, not overshoot it. A calc() offset like 2.5vw + 1rem gives you a floor that respects the root font size plus a slope that stays inside the guardrails.
2. The minimum is set below readable
The mirror image: clamp(8px, 2vw, 24px) on a small phone gives you text nobody can read without zooming. I have seen people set the minimum to whatever made the desktop math elegant and never check the phone. Do not set body text below 14px, and test the minimum on an actual small screen, not just in a narrowed desktop window. DevTools device mode lies about how text feels in your hand.
3. The values are in the wrong order
clamp() takes MIN, preferred, MAX, in that order. If you write clamp(48px, 2.5vw, 20px), with the min larger than the max, the spec resolves the conflict in favor of max: you get a fixed 20px and the text never budges. The browser will not warn you. This one usually arrives via copy-paste from a tutorial where the author was demonstrating something else entirely. Read the three values out loud in order whenever a clamp() looks dead.
4. You asked clamp() to do a media query's job
Clamp scales a value. It does not change layout. The hamburger menu that never appears, the grid that collapses into a single unreadable column, the sidebar that refuses to stack: none of those are value problems, and no amount of clamp() tuning fixes them. I tried the all-clamp diet once on a side project and spent an evening undoing it. Keep media queries for layout and component behavior. Use clamp() for the sizes and spacing inside those layouts.
5. The line-height did not come along
Fluid font size with a fixed line-height gets cramped at the top of the range and airy at the bottom. If your headings scale from 20px to 48px but the line-height sits at 24px, the big end overlaps and looks broken in a way people blame on the clamp(). Pair fluid sizes with fluid or unitless line-height. A unitless 1.2 on a heading scales with the font automatically, which is one less thing to debug.
6. The zoom trap
This is the one that passes every visual test and fails the audit. Viewport units do not respond to browser zoom the way relative units do, so text sized with a vw-based clamp() can refuse to reach 200% of its size when a user zooms in. Adrian Roselli demonstrated this years ago and it is still true: it is a WCAG 1.4.4 resize-text failure hiding inside otherwise fine CSS. The preferred value with a rem component, like the fix at the top of this page, behaves better under zoom because part of the value is anchored to the root font size. Test every clamp() at 200% zoom before you ship it. It takes thirty seconds.
If you want the middle value computed instead of guessed, that is what the calculator on this site is for. Punch in the size you want at your small and large breakpoints and it hands you the clamp() line, with the math shown so you can sanity-check the slope.
Frequently asked questions
Why is my CSS clamp font size not scaling?
Usually the viewport value is too aggressive and the clamp pins to its maximum on most screens. With clamp(16px, 10vw, 32px), a 400px phone already computes 40px from the vw term. Use smaller vw values, in the 1vw to 5vw range, so the preferred value lands inside the range at the viewports you care about.
What happens if the min value is larger than the max in clamp()?
The browser resolves the conflict in favor of the max value, so clamp() returns max and behaves like a fixed value. No warning, no error. Check the order of your three values whenever a clamp() looks dead.
Can clamp() with vw units fail accessibility checks?
Yes. Viewport units do not scale with browser zoom the way relative units do, so vw-based text can fail WCAG 1.4.4 resize text at 200% zoom. Test every clamp() value at 200% zoom, and prefer preferred values with a rem component.
Should I replace all my media queries with clamp()?
No. Clamp() scales values like font sizes, padding, and widths. Media queries handle layout and behavior changes, like collapsing navigation. Asking clamp() to do layout work is the mistake that breaks pages.
Get the clamp() math right the first time.