title: "CSS Clamp Generator: Fluid Typography and Spacing Without Media Queries" slug: css-clamp-generator-guide tool: css-clamp-generator category: css type: cluster

CSS Clamp Generator: Fluid Typography and Spacing Without Media Queries

I used to keep a media query graveyard at the bottom of every stylesheet. A hero heading would be 28px on phones, then a breakpoint bumped it to 36px, another to 44px, another to 56px on wide screens. Four breakpoints for one heading, and it still looked jumpy: the text sat frozen at 36px across a huge range of tablet widths and then jerked to the next size the instant a breakpoint tripped. When I rebuilt the marketing site for one of my Laravel products, I deleted all of that and replaced each of those headings with a single clamp() line. The type now grows smoothly with the window, and the stylesheet is shorter and calmer.

That is the whole promise of fluid sizing, and it is why I built the CSS clamp generator on Toolz.dev. You give it a small size, a large size, and the viewport range they map to, and it returns one line of CSS that interpolates every size in between.

TL;DR: clamp(min, preferred, max) returns a value bounded between a minimum and a maximum, using a preferred value in the middle. The generator computes the preferred value as a fixed rem term plus a vw term, so one declaration scales font size or spacing smoothly across the viewport with no media queries. Use rem bounds for accessibility, and preview the computed size at each width before you ship.

What is CSS clamp() and what does it do?

clamp() is a CSS function that returns a value locked between a lower and an upper bound, defined in CSS Values and Units Level 4. It takes three arguments in the order clamp(minimum, preferred, maximum). The browser evaluates the preferred value, and if that value would fall below the minimum it uses the minimum, and if it would rise above the maximum it uses the maximum. Everywhere in between, it uses the preferred value.

The function is defined in the CSS Values and Units Module Level 4 specification (https://www.w3.org/TR/css-values-4/), alongside its cousins min() and max(). What makes it powerful for layout is that the preferred value can mix units. If you make the preferred value depend on vw, which is one percent of the viewport width, then the result scales with the window, while the minimum and maximum keep it from ever getting too small or too large.

Why should I stop writing media queries for sizing?

Media queries are step functions. A size holds flat, then jumps at a breakpoint, then holds flat again. That produces two annoyances. First, the jump is visible: a heading snaps from one size to the next as you resize, which looks unpolished. Second, the flat regions are a compromise: a size chosen to look acceptable across the whole tablet range is, by definition, slightly too big at one end and slightly too small at the other.

Fluid sizing with clamp() is a continuous function instead. The value changes by a hair for every pixel of viewport width, so there is no jump and no compromise size. One heading that reads well at 320px and well at 1280px will also read well at every width between them, because it is computed for that exact width. You trade a stack of breakpoints for a single line, and the line behaves better than the stack did.

There is a maintenance win too. When a designer changes the target sizes, you edit one declaration instead of hunting through four media queries to keep them consistent. Fewer places to change means fewer places to get it wrong.

How does the generator calculate the preferred value?

This is the part most people take on faith, so here is the actual math the tool runs. You give it two points: the minimum size at the minimum viewport, and the maximum size at the maximum viewport. A straight line through two points is fully determined, so the tool finds that line.

The slope is the change in size divided by the change in viewport width: (maxSize - minSize) / (maxViewport - minViewport), measured in pixels of size per pixel of viewport. The line also has a y-intercept, the size the line would have at a viewport of zero, which is minSize - slope * minViewport.

Now the trick that turns that line into CSS. A length of Xvw equals X percent of the viewport width, so the viewport-proportional part of the line becomes (slope * 100)vw, and the intercept is emitted as a fixed rem value. The result is a preferred value like 0.8333rem + 0.8333vw. Wrap it in clamp() with the two sizes as bounds and you get, for the classic example of 16px at 320px growing to 24px at 1280px, clamp(1rem, 0.8333rem + 0.8333vw, 1.5rem).

You do not have to trust that blindly, which is why the tool shows a preview table of the computed size at several viewport widths. At 320px it reads 16px, at 1280px it reads 24px, and the values in between confirm the line does what you expect.

Should I use px or rem for clamp() values?

Use rem for the bounds. A rem is relative to the root font size, so when a user increases their browser's default font size for readability, sizes expressed in rem scale up with it. Sizes expressed in px do not, which quietly breaks that accessibility control. This is a long-standing recommendation and it applies to clamp() just as it applies to any font-size.

The generator lets you type input sizes in either px or rem because designers hand off px values far more often, but it always emits the bounds in rem, converting with the root font size you set, which defaults to 16px. If your project uses a different base, set it and the output adjusts. If you want to double-check a raw px-to-rem conversion outside the clamp workflow, the CSS unit converter does exactly that and shares the same conversion logic, so the numbers line up.

Can I use clamp() for spacing, not just font size?

Yes, and this is where it stops being a typography trick and becomes a layout tool. clamp() works on any length property: margin, padding, gap, width, height, and line-height all accept it. A section that needs breathing room can use a fluid padding that grows from 24px on phones to 80px on desktops in one declaration, so the whitespace scales with the screen instead of feeling cramped on large monitors or wasteful on small ones.

I use fluid gap on card grids constantly. The cards themselves can be sized with the grid, but a fluid gap keeps the rhythm between them proportional at every width. The clamp generator does not care what property you paste the value into, so the same tool covers type, spacing, and layout dimensions.

How does clamp() compare to other responsive techniques?

Technique	Scaling	Lines of CSS	Smoothness
Fixed size	None	1	N/A
Media queries	Stepped at breakpoints	Several per element	Jumps at each breakpoint
Raw vw unit	Continuous, unbounded	1	Smooth but can get too small or large
clamp()	Continuous, bounded	1	Smooth and safely bounded

The raw vw row is worth dwelling on, because reaching for vw alone is the common half-step people take before they discover clamp(). A pure vw font size scales smoothly, but it has no floor and no ceiling, so it becomes unreadably small on phones and comically large on wide monitors. clamp() is vw with guardrails, which is almost always what you actually wanted.

Why is my clamp() value not changing?

Two causes account for nearly every "it is stuck" report. The first is that the minimum and maximum sizes are equal, which makes the slope zero, so the preferred value is a constant and the size never moves. If you want it fixed, that is fine, but if you expected scaling, give the two sizes different values.

The second is that you are testing outside the viewport range. Below the minimum viewport, clamp() correctly locks to the minimum size, and above the maximum viewport it locks to the maximum. So if your range is 320px to 1280px and you are resizing a 1600px monitor, the value will sit at the maximum and look frozen, exactly as designed. Test at a width between your two viewports to see the scaling. The preview table in the clamp generator sidesteps this by showing the computed value across the range at a glance.

How does this fit the rest of a CSS workflow?

Fluid sizing is one piece of the polish layer. Once type and spacing scale smoothly, the next things I tune are the decorative details, and the same site usually leans on a few tools together.

I pair the clamp generator with the gradient generator for fluid hero sections, and with the box shadow generator for elevation that stays consistent across components. Color runs through the color converter so every value is expressed in the exact format each context needs. Those four cover most of what I reach for when turning a rough layout into a shipped one.

If you want the wider picture of how these fit together, I wrote up my everyday setup in the web developer toolkit, and there is a dedicated walkthrough of gradients in the CSS gradient generator guide that pairs naturally with fluid layout work.

Do all browsers support clamp()?

Yes. clamp(), along with min() and max(), is supported across all modern browsers, including current Chrome, Firefox, Safari, and Edge, and has been for years. For the vast majority of projects you can use it with no fallback at all.

If you must support a genuinely ancient browser, the graceful pattern is to declare a static value on the line before the clamp() declaration. Browsers that do not understand clamp() ignore the line they cannot parse and keep the static value, while modern browsers apply the fluid one. That progressive-enhancement approach costs one extra line and removes any risk, but in 2026 you rarely need it.

A worked example: fluid section padding

Let me walk a real case end to end, because the abstract formula clicks faster with numbers. Say a marketing section should have 24px of vertical padding on the smallest phones and 80px on large desktops, scaling between a 320px and a 1440px viewport. Those are my two points: 24px at 320px, and 80px at 1440px.

The slope is (80 - 24) / (1440 - 320), which is 56 / 1120, or 0.05 pixels of padding per pixel of viewport. The intercept is 24 - 0.05 * 320, which is 24 - 16, or 8px, and 8px at a 16px root is 0.5rem. The vw coefficient is 0.05 * 100, which is 5vw. So the preferred value is 0.5rem + 5vw, and the full declaration is clamp(1.5rem, 0.5rem + 5vw, 5rem), since 24px is 1.5rem and 80px is 5rem.

Drop that on padding-block and the section breathes correctly at every width: tight on phones, generous on desktops, and smoothly proportional in between. The generator produces exactly this for you, and its preview table confirms the padding reads 24px at 320px and 80px at 1440px so you can trust the line before you paste it.

How do I test a clamp() value?

The fastest sanity check is the preview table in the generator, which evaluates the clamped value at a spread of common widths. But it is worth knowing how to verify one live in the browser too. Resize the window and watch the property with DevTools open: the computed value in the styles panel updates continuously, and you can confirm it stops changing exactly at your two viewport bounds. That live check is how I caught a stuck value once that turned out to be equal min and max sizes, the classic zero-slope mistake.

For a value used on font-size specifically, also test at increased browser zoom and increased default font size. Because the bounds are in rem, the whole curve should scale up with the user's font-size setting, which is the accessibility behavior you want and the reason the generator emits rem rather than px. If it does not scale, check that you did not hardcode a px bound somewhere downstream.

Frequently asked questions

What does CSS clamp() do?

clamp() returns a value bounded between a minimum and a maximum. It takes three arguments, clamp(min, preferred, max), and the browser uses the preferred value unless it would fall below the minimum or rise above the maximum, in which case it uses that bound. This lets one declaration behave responsively without media queries.

How does the generator calculate the preferred value?

It computes the value as a straight line through your two points: the minimum size at the minimum viewport and the maximum size at the maximum viewport. That line is expressed as a fixed rem term plus a vw term, so the value grows proportionally with the viewport width while clamp() keeps it inside your bounds.

Should I use px or rem for clamp() values?

Use rem for the bounds so the value respects a user who changes their browser font size, which is better for accessibility. This generator accepts input in either px or rem and always emits the bounds in rem, converting with the root font size you set (16px by default).

Can I use clamp() for spacing, not just font size?

Yes. clamp() works on any length property, including margin, padding, gap, width, height, and line-height. Fluid typography is the most common use, but the same generated value fluidly scales spacing and layout dimensions across the viewport range.

What viewport range should I choose?

A common range is 320px for the smallest phones to about 1280px or 1440px for large desktops. The minimum size holds below the lower viewport and the maximum size holds above the upper viewport, so pick a range that matches where you want the scaling to start and stop.

Why is my clamp() value not changing?

If the value stays fixed, the minimum and maximum sizes are probably equal, which produces a zero slope, or the viewport is outside your range so clamp() is locked to a bound. Check that the two sizes differ and that you are testing at a width between the minimum and maximum viewports.

Do all browsers support clamp()?

Yes. clamp(), along with min() and max(), is supported in all modern browsers including Chrome, Firefox, Safari, and Edge. For very old browsers you can supply a static fallback value on the line before the clamp() declaration.

Is the CSS clamp generator free and private?

Yes. The generator is completely free with no signup or limits, and all calculations run in your browser with client-side JavaScript, so the values you enter never leave your device and the tool works offline once the page has loaded.