Fluid Typography clamp() — Stop 47 media queries
Design handoff arrives with type specs at 360, 768, 1024, 1280, and “desktop large.” Someone translates that into five @media blocks that bump font-size by 1–2px each time. Between breakpoints the scale feels stuck; past the last one it jumps. You did not ship fluid type — you shipped a staircase.
clamp() gives you a continuous ramp between a minimum and maximum size, driven by viewport width (or container queries when you are ready). Done right, you delete most of those media queries. Done wrong, you get unreadable mobile text or enormous headlines on ultrawide monitors.
The formula without the mystery
h1 {
font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem);
}Read it as: never smaller than 1.75rem, never larger than 3rem, and between those bounds prefer 1.2rem + 2.5vw.
The preferred middle term is usually Rem + vw so the slope matches your design range. You pick two viewport widths and two font sizes, then solve for the linear equation. Calculators exist so you are not rearranging algebra during standup — including a browser fluid typography clamp helper.
Example design intent:
- At 320px viewport → body 16px
- At 1200px viewport → body 20px
That slope becomes something like clamp(1rem, 0.93rem + 0.36vw, 1.25rem) depending on root font size. Always express the clamp bounds in rem so user zoom still works.
Why vw-only text is an accessibility footgun
/* Avoid this */
p { font-size: 2.5vw; }Pure vw scales with the viewport even when the user zooms text. On some browsers that fights the user’s preferred size. Pairing rem with a limited vw inside clamp() keeps a floor and ceiling tied to the root, which respects zoom much better.
Also test:
- 320px width — is the minimum still readable?
- Zoom 200% — do headings blow out the layout or stay usable?
- 4K / 2560px — does the max stop the type from becoming a billboard?
If the answer to any is “looks wrong,” adjust min/max before inventing another breakpoint.
Where media queries still belong
Fluid type does not kill every query. Keep media (or container) queries for:
- Switching from single-column to multi-column layouts
- Changing
line-heightor letter-spacing for dense UI - Swapping display vs body fonts
- Reducing motion or contrast variants
Do not keep queries that only exist to nudge font-size by one pixel at 900px.
A practical scale for product UI
| Role | Example clamp | Intent |
|---|---|---|
| Body | clamp(1rem, 0.95rem + 0.25vw, 1.125rem) | Subtle growth |
| H2 | clamp(1.5rem, 1.2rem + 1.2vw, 2.25rem) | Noticeable but capped |
| Display | clamp(2rem, 1rem + 4vw, 3.5rem) | Marketing hero only |
| Small UI | clamp(0.75rem, 0.7rem + 0.2vw, 0.875rem) | Labels — keep tight |
Document the min viewport, max viewport, and rem root assumption next to the tokens. Future you will thank present you when someone asks why H1 “feels different” after a redesign.
FAQ
Can I use clamp() with container query units (cqi)?
Yes, and it is often better for cards and sidebars than viewport units. Same min/preferred/max shape.
My designer gave px at five breakpoints. Must I match all five?
No. Pick the smallest and largest meaningful sizes and fluidly interpolate. Extra midpoints are usually noise.
Does clamp replace a modular type scale?
It complements one. Keep ratio between roles (body vs H2 vs H1); use clamp so each role breathes across widths.
Stop writing font-size media queries every 80px. Set a floor, a ceiling, and a slope — then verify at the edges, not only at the mock widths.