For years, responsive typography meant choosing a font size for phones, another for tablets, and another for desktops, and switching between them at breakpoints. The result was a staircase: text jumped from one size to another as the viewport crossed each breakpoint, and sizes between breakpoints were compromises. The CSS clamp() function offers a smoother approach. It lets a size grow fluidly with the viewport, while guaranteeing that it never goes below a minimum or above a maximum. The text scales continuously, like water finding its level, instead of stepping between fixed sizes.
The CSS Clamp Calculator does the mathematics that makes clamp() work. You enter the minimum size, the maximum size, and the viewport widths at which those sizes should apply, and it returns the clamp() value for your stylesheet. The mathematics is simple linear interpolation, but it is easy to get wrong by hand, and a small arithmetic error produces a size that overshoots at one end of the range or undershoots at the other. The calculator removes that risk.
How the tool works
The clamp() function takes three values: a minimum, a preferred value, and a maximum, written as clamp(minimum, preferred, maximum). The browser uses the preferred value when it falls between the minimum and the maximum, and it clamps the result to the minimum or maximum when the preferred value would fall outside that range. For fluid type, the preferred value is expressed using viewport units — typically vw, where 1vw is one percent of the viewport width — plus a fixed pixel component that anchors the line.
The calculator derives the preferred value from your four inputs: the minimum size and the viewport width at which it should apply, and the maximum size and the viewport width at which it should apply. Between those two viewport widths, the size grows linearly from the minimum to the maximum. Below the smaller viewport width, the minimum applies. Above the larger viewport width, the maximum applies. The result is a size that is always readable, never tiny on a phone and never enormous on a wide monitor, and that changes smoothly everywhere in between.
That smoothness is the real benefit. A heading that grows gradually as a window widens feels intentional in a way that a heading jumping between sizes at a breakpoint does not. It also reduces the number of breakpoints you need to manage: one clamp() value can replace several media queries for a single element, which makes stylesheets shorter and easier to maintain.
A worked example
Suppose you want a heading that is 16 pixels on a narrow phone screen 320 pixels wide, and 24 pixels on a desktop screen 1,200 pixels wide, growing smoothly between those widths. The calculator's arithmetic proceeds as follows.
First, the slope: the size must grow by 24 minus 16, which is 8 pixels, over a viewport range of 1,200 minus 320, which is 880 pixels. The slope is 8 divided by 880, which is 0.00909 pixels of font size per pixel of viewport width. Expressed in viewport units, where 1vw equals 1 percent of the viewport width, that slope is 0.909vw.
Second, the intercept: the fixed pixel component that, added to the viewport component, gives the correct size at the ends of the range. At a viewport width of 320 pixels, the viewport component contributes 0.00909 multiplied by 320, which is 2.91 pixels. The minimum size is 16 pixels, so the intercept is 16 minus 2.91, which is 13.09 pixels.
The resulting clamp() value is therefore clamp(16px, 13.09px + 0.909vw, 24px). Check it at both ends. At 320 pixels wide, the preferred value is 13.09 plus 0.909 percent of 320, which is 13.09 plus 2.91, which is 16 pixels: the minimum, as required. At 1,200 pixels wide, the preferred value is 13.09 plus 0.909 percent of 1,200, which is 13.09 plus 10.91, which is 24 pixels: the maximum, as required. Between those widths, the size grows smoothly, and outside them, the clamps hold it steady.
That verification step — checking both ends — is worth doing every time, because it catches the two most common errors: a slope with the wrong sign, which would make text shrink as the screen grows, and an intercept that shifts the whole line up or down.
Common mistakes
The first mistake is choosing a range that is too wide. A heading that grows from 16 pixels to 48 pixels across the viewport range will look dramatic, but it will also dominate small tablets in the middle of the range, where the size is already large. Keep the minimum-to-maximum ratio modest — a growth of roughly one and a half times is a good starting point — and let hierarchy come from weight and spacing as well as size.
The second mistake is forgetting the minimum. A purely fluid size with no lower bound becomes unreadably small on a narrow phone, which is exactly the device where readability matters most. The minimum in clamp() is not optional decoration; it is the guarantee that your smallest readers, on the smallest screens, can still read your text.
The third mistake is applying fluid sizing to everything. Body text usually benefits from a narrow size range or a fixed size, because long passages at rapidly changing sizes are tiring to read. Reserve generous fluid scaling for headings and display text, where size is part of the design, and keep body text stable.
The fourth mistake is testing only at the extremes. A clamp() value that is correct at 320 and 1,200 pixels can still look wrong at 700 pixels, where the size is mid-range and may sit awkwardly against other elements. Test at several widths across the range, including the widths your visitors actually use, and adjust the minimum or maximum if the middle of the range disappoints.
Honest limitations
Clamp() controls size, not layout. A fluid heading inside a narrow container may still overflow, wrap awkwardly, or push other elements around, and those problems require layout solutions, not larger or smaller type. Fluid sizing also depends on the viewport, not on the container: a heading in a sidebar scales with the whole window, not with the sidebar's width, which can surprise designers who expect container-relative behaviour. Newer container query units address that case, but they are a separate technique from clamp(). Finally, the calculator's output is only as sensible as its inputs: minimum and maximum sizes chosen without regard to readability will produce a mathematically correct clamp() value that is still poor typography.
Closing
Pick a sensible minimum and maximum, let the calculator derive the fluid middle, and verify the result at both ends of the range and at several widths in between. To lay out the page that holds your fluid type, try the CSS Grid Generator, and to move elements within it, see the CSS Transform Generator. For cleaning up the stylesheet that holds these rules, read CSS Formatter: Clean Up Messy Stylesheets Fast.