CSS clamp() Generator

Build fluid font-size clamp() rules between two viewport widths.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Builds a responsive font rule: it solves the straight line joining a minimum size at one viewport width to a maximum at another, and writes it as a ready-to-paste CSS clamp() rule with the sizes in rem and the slope in vw.

How to use it

1Enter Min size and Max size in pixels — these become the two rem bounds.
2Enter Min viewport and Max viewport in pixels, the widths at which those two sizes should be reached.
3Copy the generated rule, and resize your window to watch the sample sentence below it scale for real.

Example

Input: Min size 16, max size 32, min viewport 360, max viewport 1280
Output: font-size: clamp(1rem, 1.7391vw + 0.6087rem, 2rem);

Pixels are divided by 16 to reach rem, so the rule assumes a 16px root font size and will be off if you have changed it. Nothing stops you entering a min size larger than the max: the slope simply goes negative and CSS resolves clamp() with an inverted range to the minimum, giving a rule that is permanently stuck at the larger size. Only the viewport pair is checked — enter a max viewport that is not greater than the min and the output is replaced by "Enter positive numbers; max viewport must be larger than min viewport."

What happens to your data

Four numbers is the entire input, and the work is a two-point line fit — slope, then intercept — done in JavaScript as you type. There is no request of any kind, no saved preference to carry between visits, and the live preview is nothing more than the generated clamp() expression assigned to one paragraph's inline font-size.

Last updated August 2026

A heading that looks right at 1440px wraps into four lines on a phone, so you add a media query. Then the tablet width needs one. Then someone opens the page at 900px and it is wrong again. Fluid typography is the other answer: one declaration that describes the size at every width rather than three that describe it at three.

Before generating anything, decide whether the size should step or slide. A media query jumps — one size, then suddenly another — and that jump is right when the whole layout changes at that width. clamp() slides, drawing a straight line between two sizes at two viewport widths and holding flat outside them. If only the number is changing, the line replaces the rules; if the design becomes a different thing at a breakpoint, keep the query.

The straight line is also the limit. There is no curve and no exception at some width in the middle: choose the two anchor points and everything between them is settled. The rule reads viewport width alone, so it has no idea how wide the column or sidebar holding the text happens to be. And it sizes a single property — what comes out here is a font-size, and anything else you want fluid needs its own rule.

The usual mistake is picking the minimum to suit the design rather than the reader. That lower bound is the size your text will be on the narrowest screen you support, which is also where it is hardest to read, so set it from what is comfortable on a phone rather than from what looks balanced in a desktop mockup.

How it works

Toolvore treats your four numbers as two points on a graph — a size at a narrow viewport, a size at a wide one — and finds the straight line through them. The gradient of that line becomes the vw term, multiplied by 100 because 1vw is a hundredth of the viewport, and the value the line would take at zero width becomes the rem constant added to it. Those two, wrapped in clamp() between the lower and upper sizes, are the whole output. Figures are rounded to four decimal places with trailing zeros dropped, so the rule reads cleanly rather than being exact to the pixel; at ordinary text sizes that rounding sits well below one device pixel. The weakness is in what the arithmetic cannot see. Viewport width is the only input, so text in a narrow container still scales to the window — the sample sentence in the preview reflows with your browser window for exactly that reason, not with the box around it. Nothing is produced for line-height, letter-spacing or spacing either; the declaration is a font-size, and each further property needs its own line fitted the same way.

Common use cases

Replacing three font-size media queries on a hero heading with one rule
Stopping a display heading from overflowing on a 360px phone
Sizing a section title that should keep growing from tablet to wide desktop
Working out the vw and rem terms for a level of a type scale
Checking how a size behaves at the widths between two breakpoints
Matching the mobile and desktop sizes in a mockup with one declaration

Frequently asked questions

What does the clamp() function actually do in CSS?＋

clamp() takes three values — a minimum, a preferred value and a maximum — and resolves to the preferred one unless it falls outside those bounds, in which case it resolves to whichever bound it hit. For fluid type the preferred value is the part that moves: an expression mixing a viewport unit with a fixed one, so it grows as the window grows, while the two bounds stop it shrinking below one size or running past another. It is plain CSS rather than a preprocessor feature, valid anywhere a length is allowed, and supported across current browsers.

Why does the middle value need a rem term as well as vw?＋

Because a size written purely in vw ignores the reader. Page zoom scales viewport units along with everything else, but a text-only size increase — the font-size setting in browser preferences, which plenty of people rely on — does not change the viewport at all, so vw-only text refuses to grow when someone asks it to. A rem constant restores that, because rem is relative to the root font size and the setting does move it. The rules generated here always take the shape of a vw term plus a rem term, and the rem part falls to zero only when your two sizes and two widths happen to sit in the same ratio.

Should body text be fluid, or only headings?＋

Headings gain the most, because they are the sizes that break — a display heading tuned for a wide screen is what overflows or wraps badly on a phone. Body text has far less room to move: the comfortable range for paragraph text is narrow, so a fluid rule across it usually buys a point or two and risks dropping below readable at the small end. Many type scales leave body copy at one fixed size and make only the levels above it fluid. If you do make it fluid, keep the minimum at the size you would have chosen anyway and let the maximum do the work.

Which viewport widths should I use as the anchor points?＋

The narrowest width you genuinely support, and the width past which the design stops changing. The narrow end is usually a real phone width rather than the smallest number you can imagine; anchoring lower stretches the line across widths nobody visits and leaves the size smaller than you intended at the widths they do. The wide end is often where your content container reaches its maximum, since beyond that the layout is fixed and the text has no reason to keep growing. Outside both anchors clamp() holds flat, which is what keeps a heading sane on an ultrawide monitor.

Does anything I type here get uploaded or saved?＋

No. The four numbers live in the component's own state while the tab is open, the line fit runs in JavaScript on each keystroke, and there is no request, no account and no stored preference — reload and the fields are back to their starting values of 16, 32, 360 and 1280. The preview is the generated expression applied as an inline font-size to one sentence already on the page, so even that reaches nothing outside. The Copy button hands the rule to your clipboard through the browser's own clipboard API, and closing the tab is the entire cleanup.

Can clamp() be used for padding, margins and gaps too?＋

Yes — it is valid anywhere CSS accepts a length, so padding, margin, gap, width and border-radius all take it, and fluid section spacing is one of its better uses. What comes out here is a font-size declaration specifically, so reusing the maths elsewhere means changing the property name yourself and keeping the value as generated. Two cautions. Fluid spacing compounds, and several padded elements shrinking at once takes more out of a narrow layout than any single rule suggests. And a fluid width interacts with flex and grid sizing in ways worth testing rather than assuming.

Do I still need media queries if I use clamp()?＋

Usually fewer, sometimes none, but they answer different questions. clamp() varies a number smoothly; a media query switches which rules apply at all. Anything that is not a number on a line — a sidebar dropping below the content, navigation collapsing, a weight change, an element disappearing — still needs a query, and that is most of what breakpoints were ever for. The overlap is a stack of font-size overrides, where one fluid rule is clearer and also covers the widths between breakpoints that the overrides never addressed. The two combine happily: a query can change which clamp applies.

Why does my fluid text ignore the width of the sidebar it sits in?＋

Because vw measures the viewport, not the parent element. A heading inside a 300px sidebar and the same heading across a full-width hero see identical viewport units and come out the same size, which is rarely what a component author wants. Container query units are the fix: cqi, cqw and their siblings are relative to the nearest ancestor given a container-type, so a rule written in those scales with the box rather than the window. The maths is the same straight line — same slope, same offset — with the unit swapped and container widths in place of viewport widths, so a rule from here adapts by hand.