The Container That Stopped Needing Four Breakpoints

Published October 28, 2026

CSS clamp() for fluid container max width starts from a complaint I hear in code review more than any other: the container is either too wide on a monitor or too tight on a phone, and the fix is always another breakpoint. A container set to max-width: 1200px with padding looks fine on a laptop and leaves a wall of empty space on a 27 inch monitor, because the text column sits in the middle of a very wide box or stretches to the full 1200 pixels and the lines run long. A container set to width: 90% looks fine on a phone and thin on a tablet. One clamp() line covers the whole range, and it does it without a single media query for width.

The line most article layouts want is this:

.container {
  width: clamp(320px, 90vw, 720px);
  margin-inline: auto;
}

Read it left to right. The floor is 320 pixels, which is the narrowest phone you should still design for. The preferred value is 90vw, which leaves a 5 percent gutter on each side at every size. The ceiling is 720 pixels, which keeps a line of body text somewhere near 70 to 80 characters at a normal font size. At a 390 pixel phone viewport, 90vw is 351 pixels, inside the range, so the container is 351 wide. At a 900 pixel tablet viewport, 90vw is 810, capped to 720. At a 1920 pixel monitor, 90vw is 1728, capped to 720 again. The container stops growing exactly where reading stops being comfortable, and it never gets narrower than a phone can use.

That ceiling choice is where I disagree with a lot of boilerplate. Most starter templates set a container ceiling of 1200 or 1280 pixels, which is a fine ceiling for a dashboard or a card grid, and a bad one for a column of prose. A 1200 pixel text column at 16 pixels font size gives lines of 130 characters or more, and long lines tire readers out faster than any font choice will. If your page mixes prose and cards, give the prose its own narrower container instead of stretching one wide container over both. Two containers with different ceilings is a better answer than one container that serves neither content type well.

CSS clamp() for fluid container max width, and the width versus max-width confusion

The question I get asked most about this pattern is whether the clamp() belongs on width or on max-width, and the answer is worth getting exact because the wrong choice fails silently. Put clamp() on width when the container has no other width setting, which is the common case for a centered wrapper. The browser picks a value from the clamp() range and that is the width. Put clamp() on max-width only when something else already sets the width, like width: 100%, and you want a fluid ceiling instead of a fixed one. A max-width line on its own does not make an element any particular width; it only stops it from growing past the cap. I have seen layouts where someone wrote max-width: clamp(320px, 90vw, 720px) on a block element inside a wide parent, wondered why it still stretched full width on a phone, and blamed clamp(). The element was full width because nothing told it to be narrower. The clamp() on max-width was doing its job. The width was simply never set.

There is a second trap, and it is less obvious. A container using 90vw will overflow on some phones even when the clamp() math is right, and the culprit is almost always padding or a wide child. If box-sizing is not border-box, padding adds to the clamp() width, and a 351 pixel container with 24 pixels of padding on each side becomes 399 pixels wide on a 390 pixel screen. A long URL, a wide table, or an image with a fixed pixel width can do the same thing from inside. Set border-box globally, give images max-width: 100%, and let tables scroll horizontally inside their own wrapper. Those three habits fix more container overflow than any change to the clamp() values will.

One more thing, since you are probably wondering whether this kills media queries: it does not, and you should not let it. Width is one property. The moment your layout needs to stack two columns into one, swap a horizontal nav for a menu button, or change a grid from three tracks to one, that is a layout decision, and layout decisions still belong in media queries or container queries. What clamp() kills is the width ladder: the four media queries that existed only to nudge the container wider at each breakpoint. Keep the queries that change structure. Delete the ones that only change size. Use the CSS Clamp Calculator to generate your container values and check the three viewport sizes above before you ship, because a container that reads well at 390, 900, and 1920 will read well almost everywhere between them.

I will leave one thread open on purpose. The 720 pixel ceiling I used here assumes 16 to 18 pixel body text. If your site sets body text at 20 pixels or larger, 720 pixels gives shorter lines, and you may want a wider ceiling. I have not settled on a single rule for that trade, because it depends on your type scale, and the honest answer is to test with your actual font before copying my number.

Frequently asked questions

Related guides

• CSS clamp() for Fluid Hero Section Height: A Hero That Scales Without Breakpoints
• CSS clamp() for Fluid Sidebar Width: A Sidebar That Scales Without Breakpoints
• CSS clamp(), Finally Explained: Min, Preferred, and Max