Skip to content
ToolBoxGeniehome

CSS Clamp Generator

Developer Tools · Added

A heading that reads well at 320px is usually too small at 1440px, and one sized for the desktop overflows the phone. Media queries solve that in steps; clamp() solves it as a smooth line between two points you choose. This builds that line — a minimum, a maximum and the rem-plus-vw expression that joins them — and shows what the result actually computes to at each common screen width, so you can check the curve rather than trusting it.

px

What it should be on a phone

px

What it should be on a desktop

px

Below this it stops shrinking

px

Above this it stops growing

px

16 unless your CSS changes it

Presets:

How to use the css clamp generator

  1. 1Set the size you want at the narrow end and the size you want at the wide end, both in pixels.
  2. 2Set the two viewport widths those sizes apply at. Outside that range the value holds at the nearer bound.
  3. 3Set the root font size if your CSS changes it from the browser default of 16px.
  4. 4Press Generate and copy the declaration.
  5. 5Check the table underneath, which shows the computed size at nine screen widths and marks where the value is being held at a bound rather than scaling.

Examples

Fluid body text

Input
16px at 320px, 18px at 1280px
Result
clamp(1rem, 0.9167rem + 0.2083vw, 1.125rem)

A gentle slope. Body text rarely wants to move much — a couple of pixels across the whole range is usually plenty.

A page heading

Input
28px at 320px, 56px at 1280px
Result
clamp(1.75rem, 1.1667rem + 2.9167vw, 3.5rem)

Headings carry fluid scaling far better than body copy, which is why they are what this technique is usually used for.

A value that shrinks as the screen grows

Input
32px at 320px, 16px at 1280px
Result
The bounds are written in the order clamp() needs, and the tool says so

Left the intuitive way round, the browser silently pins the value and nothing scales at all.

About the css clamp generator

The line, and where the numbers come from

Two points define a line: the size you want at the narrow viewport and the size you want at the wide one. The slope is the difference in sizes divided by the difference in widths — how many pixels the value gains per pixel of screen. Multiply that by 100 and it is a vw figure, since 1vw is one hundredth of the viewport width.

The intercept is where that line would cross a viewport width of zero, which is a hypothetical screen but a perfectly real number. Expressed in rem it becomes the constant term of the preferred value. Adding the two gives a value that passes exactly through both of your chosen points and interpolates smoothly between them.

Outside the range, the bounds take over. Below the narrow viewport the value holds at the minimum; above the wide one it holds at the maximum. The table in the results marks which rows are scaling and which are held, which makes it easy to see whether the range you chose covers the screens you care about.

When a clamp is the wrong tool

Fluid scaling is continuous, and some design changes are not. If a heading needs to drop from three lines to one, or a layout needs to switch from stacked to side-by-side, that is a container query or a media query — no amount of smooth interpolation expresses a change in arrangement.

It is also worth resisting the temptation to make everything fluid. A page where every size scales independently loses its typographic relationships: the ratio between a heading and its body text drifts as the screen changes, and what looked balanced at one width looks wrong at another. A common approach is to make one value fluid and derive the rest from it with a fixed ratio, so the relationships hold while the overall scale moves.

Finally, watch the extremes. A steep slope that looks reasonable between 320px and 1280px can produce something absurd on a 3440px ultrawide if the maximum is set too high, and something unreadably small on a narrow phone if the minimum is too low. The samples table exists to make both ends visible before the CSS ships, and the tool warns when a floor falls below comfortable reading size.

Frequently asked questions

Why not just use vw on its own?
Because it breaks text zoom. A size given purely in viewport units is calculated from the window width and ignores the reader's browser text-size setting entirely, so somebody who has set 200% text gets no change at all. That fails WCAG success criterion 1.4.4, which requires text to be resizable to 200% without loss of content or function. Keeping a rem term in the preferred value fixes it, because rem does respond to the root font size — and since the line between two arbitrary points rarely passes through the origin, that term appears on its own.
How does clamp() actually resolve?
It is equivalent to max(MIN, min(PREFERRED, MAX)). The browser computes the preferred value, caps it at the maximum, then raises it to the minimum if it fell below. That order has a consequence worth knowing: if the minimum is larger than the maximum, the minimum wins outright and the value never moves. It is legal CSS, it produces no warning, and it is exactly what happens when a size that shrinks with screen width is written the intuitive way round. This tool orders the bounds for you and says when it has.
Should I use px or rem for the bounds?
rem, which is what this generates. Pixel bounds override the reader's font size preference at exactly the moments the clamp is doing its job — at the small end for someone who needs larger text, and at the large end for someone who prefers smaller. Expressing the bounds in rem means the whole range moves with the root size, so the design keeps working for readers who have changed it. The input boxes take pixels because that is how designs are specified, and the conversion happens on the way out.
What viewport widths should I pick?
Common practice is 320px for the narrow end, since that covers the smallest phones still in use, and somewhere between 1280px and 1440px for the wide end, beyond which growth stops being useful. The exact numbers matter less than the size at each — what you are really specifying is two design decisions with a line drawn between them. A wider range gives a gentler slope and a more subtle effect.
Can I use this for padding and margins too?
Yes, and it is arguably a better fit there than for type. Section padding that is 24px on a phone and 96px on a desktop is a large ratio that reads naturally as a smooth change, whereas body text is fussier — readers notice type that shifts size between two of their own devices. Gaps, gutters, container padding and vertical rhythm all take fluid values well. The presets in the tool include a couple of spacing examples for that reason.

Related tools