CSS Clamp Generator

Build fluid clamp() values for typography and spacing — with a live curve you can actually see, a full type-scale generator, and CSS, SCSS, or Tailwind output. No media queries, no guesswork.

  • Live Curve Preview
  • Type Scale Generator
  • vw & cqw Support
  • 4 Export Formats
  • 100% Private
Generate clamp()
Unit Relative To
Quick Range
The quick brown fox jumps over the lazy dog
900px → 1rem
LevelMinMaxclamp()
900px

Common elements at a 320px → 1440px viewport range, 16px root. Copy one directly — no configuration needed.

ElementMin → Maxclamp()

Common Viewport Breakpoints

NameWidthTypical Device
XS320pxSmallest phones (iPhone SE)
Mobile375–390pxMost modern phones
Large Mobile430pxPhone max, Plus/Pro Max sizes
Tablet768pxiPad portrait
Desktop1280–1440pxCommon laptop viewport
Wide1920pxFull HD desktop monitor

More Than Just a Formula

Every generator can compute a clamp(). Not every one shows you the curve.

  • Live Curve Visualization

    See the actual flat-ramp-flat shape of your clamp(), with a marker showing exactly where your simulated viewport lands.

  • Full Type Scale

    Generate an entire xs–4xl heading scale from one modular ratio, previewed live and stacked, not just a single value.

  • vw & cqw Support

    Scale against the full viewport or a component's own container — pick whichever actually matches how the element is used.

  • 4 Export Formats

    Plain CSS, a CSS custom property, an SCSS variable, or a Tailwind config snippet — whichever your codebase already uses.

  • Zero-Config Cheat Sheet

    Need a fast answer, not a configurator? Grab a ready-made clamp() for H1, body text, or section padding straight away.

  • 100% Private

    Every calculation runs in your browser. Nothing you configure is ever sent anywhere.

From Two Sizes to One Line of CSS

  1. 1

    Set the Range

    Enter your smallest and largest viewport widths, and the size you want at each end.

  2. 2

    Watch the Curve

    Drag the simulate-viewport slider and watch the preview text — and the curve marker — respond live.

  3. 3

    Copy the Output

    Grab it as plain CSS, a variable, SCSS, or a Tailwind snippet, and paste it straight into your project.

Frequently Asked Questions

clamp(MIN, PREFERRED, MAX) picks one of three values based on the current viewport: it uses PREFERRED as long as that stays between MIN and MAX, but locks to MIN below that range and MAX above it. In practice that means a font-size or spacing value that grows smoothly with the screen, then stops growing (or shrinking) once it hits the limits you set — no breakpoints required.

For simple size scaling, usually not — one clamp() declaration replaces a whole stack of media-query overrides for a single property. You'll still want media queries for layout changes that aren't about size (switching from a 3-column grid to 1 column, hiding a sidebar, reordering flex items) — clamp() only interpolates a number, it can't restructure your markup.

rem, almost always, for font-size and anything typography-related. A rem value is relative to the root font-size, so it still respects a user who's bumped up their browser's default text size for readability — a px value ignores that setting completely. px is fine for things that genuinely shouldn't scale with text size, like a fixed icon or a 1px border.

vw scales against the full browser viewport — the whole window. cqw scales against the width of the nearest ancestor with container-type: inline-size set on it, so the same component scales correctly no matter how narrow or wide the column it's dropped into. Use cqw for components reused inside sidebars, cards, or modals at different widths; use vw for page-level elements like a hero heading.

They're just the two numbers behind the linear ramp in the middle of the clamp. Slope is (maxSize − minSize) ÷ (maxViewport − minViewport) — how fast the value grows per pixel of viewport. Intercept (the y-axis intersection) is minSize − slope × minViewport — the value the line would hit at a viewport width of 0. Multiply the slope by 100 and that's the vw coefficient that goes in the middle of the clamp().

Yes. clamp() has shipped in every major browser since September 2020 (Chrome 79, Firefox 75, Safari 13.1), so unless you specifically still support Internet Explorer, there's no practical compatibility concern. If you do need an IE fallback, declare a plain px or rem value first — clamp() simply overrides it in browsers that understand it, and IE just uses the fallback.

Any CSS property that accepts a length works: padding, margin, gap, width, max-width, border-radius, letter-spacing, line-height — even grid-template-columns track sizes. The same three-value logic applies regardless of property.

This usually happens when every heading level shares the same min/max viewport range but very different size ranges — a big h1 and small body text scaling over the exact same 320–1440px window compress differently. Try giving your largest headings a slightly narrower range, or lower the ratio (e.g. from Perfect Fourth to Major Third) so the steps between levels stay proportionally consistent at both ends.

What Is CSS clamp() and Why Does It Matter?

clamp() is a CSS function that takes three values — a minimum, a preferred value, and a maximum — and returns whichever one applies at the current viewport width. Before it existed, "responsive font size" meant writing a base size and then overriding it at three or four media-query breakpoints, which produces a value that visibly jumps at each breakpoint instead of scaling smoothly. clamp() collapses all of that into a single declaration that interpolates continuously between two endpoints, then holds steady outside of them.

clamp() vs. Media Queries: When to Use Each

They're not really competing tools — they solve different problems. clamp() is for a value that should change continuously with viewport width: font-size, padding, a max-width. Media queries are for structural changes that a single interpolated number can't express: switching a grid from 3 columns to 1, hiding a sidebar, changing flex-direction. Most real layouts use both — clamp() for the sizes, media queries for the structure around them.

clamp()Media Queries
Best forContinuous scaling of a single valueStructural/layout changes
ResultSmooth interpolation, no visible jumpDiscrete steps at each breakpoint
Lines of CSSOne declarationOne block per breakpoint
Can restructure markup?No — numbers onlyYes

The Math Behind the Generator

Every clamp() this tool produces follows the same two-step calculation, sometimes called linear interpolation:

slope = (maxSize − minSize) ÷ (maxViewport − minViewport)
intercept = minSize − (slope × minViewport)

The middle "preferred" value is then written as intercept + (slope × 100)vw — multiplying the slope by 100 converts it from "per pixel" into "per vw unit," since 1vw is defined as 1% of the viewport width. Plug both endpoints back in and you'll get exactly minSize at minViewport and exactly maxSize at maxViewport, with a straight line between them.

Why Fluid Typography Reduces Layout Shift

A page that jumps from 16px to 20px body text at a single 768px breakpoint has one moment where every line of text on the page reflows at once — that's a real, visible layout shift, and enough of them can hurt your Cumulative Layout Shift score. A clamp()-based size changes by a fraction of a pixel per pixel of viewport width, so there's no single frame where the layout visibly jolts. It's not that clamp() eliminates reflow entirely — it's that it spreads the same total change across the whole scroll of viewport widths instead of dumping it all at one breakpoint.

Using rem vs. px for Font Sizes

Rem values are relative to the user's browser base font size — 16px by default, but a real number some visitors change. A font-size written in rem still respects that setting; one written in raw px does not, which is why most style guides and WCAG-adjacent checklists lean on rem for anything text-related. This generator defaults to rem for exactly that reason, though it'll happily output px if that's genuinely what your project needs — we cover the tradeoffs in more depth in our px vs. rem vs. em guide, and you can convert any value between the two with our Pixel to REM Converter.

Viewport (vw) vs. Container (cqw) Units

vw is always relative to the browser's viewport — the entire visible window, full stop. cqw is relative to the nearest ancestor that has container-type: inline-size declared on it, which means the same component can scale differently depending on where it's dropped — full width in a hero section, narrower inside a sidebar card — without you writing separate rules for each context. cqw needs a modern browser (Chrome 105+, Safari 16+, Firefox 110+) and an actual container declared upstream; if neither of those is true yet in your project, stick with vw.

Tips for Using This Generator

  • Keep the viewport range realistic. 375–1440 covers the vast majority of real traffic; stretching to 320–1920 makes the slope shallower and the scaling feel less noticeable.
  • Don't let the max size run away from you. A hero heading that hits 5rem+ on an ultrawide monitor usually looks better capped lower than the "natural" ratio would suggest.
  • For a whole page, generate the type scale once, export it as CSS variables, and reference those variables everywhere — don't regenerate a one-off clamp() per heading.
  • Test at the actual min and max viewport, not just in between — that's where a badly chosen ratio or range shows up first.