CSS Clamp Calculator

clamp(MIN, PREFERRED, MAX) returns whichever of the three values lies in the middle. The browser computes PREFERRED on every layout pass, and if the result drops below MIN it returns MIN, if it climbs above MAX it returns MAX. That single function replaces a stack of media queries: define a floor, a ceiling, and a fluid expression in the middle, and the value scales smoothly between the two endpoints. For fluid typography the PREFERRED part is a linear function of viewport width, like 0.5rem + 1.25vw, which is exactly what this calculator generates.

Fixed sizes per breakpoint jump in chunks: a heading might be 24 px below 768 px and 32 px above it, with nothing between. That produces a visible step at the breakpoint and looks awkward on the many devices that land near it. Fluid clamp values interpolate between the floor and ceiling for every pixel of viewport width, so the same heading flows from 24 px at 320 px wide to 32 px at 1440 px with no jumps. You also write one declaration instead of three or four media queries, which keeps your stylesheet shorter and easier to maintain as new device widths appear.

Rem values follow the root font size, so they respond to a user's default text-size preference. CSS pixel values still scale with page zoom, and using px does not by itself fail WCAG. Whatever units you choose, test that text can reach 200% without clipping, overlap, or loss of function.

1vw equals one percent of the current viewport width. On a 1000 px wide screen, 1vw is 10 px; on a 320 px wide screen it is 3.2 px. Inside the clamp() preferred value, multiplying the slope by 100 converts the linear coefficient (size change per pixel of viewport) into a vw coefficient. So a slope of 0.0125 px-per-vw-pixel becomes 1.25vw, which the browser evaluates fresh on every resize. Combine that with a rem intercept and you get a CSS-only fluid value with no JavaScript and no resize listeners.

Current major browsers support clamp() without a vendor prefix. Older browsers, including Internet Explorer, do not. Check your project's browser support matrix and provide a fallback declaration first when unsupported clients still matter.