At what width should a multi-column layout collapse to one?

Collapse a multi-column layout the moment any single column gets too narrow to hold its content comfortably. The trigger is the content’s minimum usable width per column, not a named device breakpoint. Ask what the narrowest column carries, body text, a card, a form field, a chart, and find the width below which that thing stops being readable or usable. When the available space divided among your columns pushes one of them under that floor, drop to a single column. The column’s own readability sets the collapse point, and it will land at different widths for different layouts.

This works because columns exist to use horizontal room well, and they stop earning their keep the instant they cannot give each piece of content enough room to function. A fixed breakpoint cannot know that, because it knows the viewport but not what is inside the columns. Two layouts at the same width can have completely different collapse needs: three columns of dense paragraph text will choke long before three columns of short labels do. Tie the decision to the content and it stays correct as the content changes. Tie it to a tablet width and it is right only by coincidence, and it breaks the day someone drops a wider element into one column or the type size changes.

Body copy makes the clearest case. Comfortable reading wants a measure of roughly forty-five to seventy-five characters per line, and below about forty-five characters text starts to feel cramped and choppy, with the eye snapping back too often. So a two-column article layout should collapse when each column would fall under that comfortable measure, which on typical type sizes happens well before any phone-versus-tablet line. A card grid behaves differently: it can hold more columns longer because each card has a known minimum, perhaps around two hundred and fifty pixels, and you collapse, or step down the column count, whenever the next card would shrink past it. A third case sharpens the point: a data table or wide chart has a hard minimum set by its own columns or axis labels, and squeezing it narrower does not just look tight, it makes numbers wrap and headers truncate, so it often must collapse, scroll horizontally, or restructure long before text would. Same principle, different number, because the content differs.

Where this breaks down is that “collapse to one” is sometimes too blunt. A four-column grid often should step to two before it ever reaches one, collapsing in stages as each width tier falls below the per-column floor, so the rule is really collapse a column whenever it drops under its content’s comfortable width, with one column as the final stage rather than the only move. And a handful of layouts have a hard editorial reason to hold two columns longer than comfort alone would dictate, in which case you accept the tighter measure deliberately rather than by accident. The exception that runs the other way is content that should never be multi-column at all on small screens, like a primary form or a checkout, where even a comfortable two-column fit is worth collapsing early so the single most important task stays linear and unmistakable. Knowing the floor is what lets you make any of these calls on purpose.

To set your collapse points, measure first. Take the narrowest content each column must hold, decide the smallest width at which it still reads or works well, and place your breakpoint where the layout can no longer give every column that width. Let the column’s readability call the moment, step the count down as needed, and you will get a layout that collapses because the content asked it to, not because a device chart told it to.