Native CSS Masonry Gallery — Free grid-template-rows: masonry Demo

Masonry — the staggered, Pinterest-style waterfall layout where items pack into whichever column has the least content so far — has always required either JavaScript (measuring each item and repositioning it) or a compromise CSS technique. grid-template-rows: masonry is a genuinely native attempt to close that gap: hand row placement to the browser's own masonry algorithm inside an ordinary CSS Grid, with a single property and zero JavaScript.

What grid-template-rows: masonry actually does

Inside a normal grid, you declare grid-template-columns as usual, but set grid-template-rows: masonry instead of a track list. The browser then places items into whichever column currently has the shortest running height, exactly like a hand-rolled masonry algorithm would, producing the familiar staggered look without you writing any placement logic. Because it's still a grid under the hood, ordinary grid item properties keep working alongside it.

The honest support story

This is genuinely experimental as of 2026: Firefox has shipped support for CSS grid masonry, but Chromium and WebKit have not — both are instead exploring a separate "item-flow" masonry proposal with different syntax, and there is no cross-browser consensus yet on the final shape of native masonry in CSS. That means grid-template-rows: masonry will render a real masonry layout in Firefox today and needs a genuine fallback everywhere else — it is not a "ships everywhere, just needs a vendor prefix" situation.

The fallback: CSS columns(), not a broken grid

Rather than degrading to a plain, non-staggered grid in unsupporting browsers, this snippet's @supports not (grid-template-rows: masonry) block switches to the long-standing multi-column technique: columns: 4 200px turns the container into a CSS multi-column layout, each card becomes a column item, and break-inside: avoid stops a card being visually split across a column boundary. It's not pixel-identical to true masonry — items fill top-to-bottom within a column before moving to the next column, rather than always choosing the globally shortest column — but it produces a genuinely staggered waterfall look with zero JavaScript in every browser.

When to reach for this vs. a JS masonry library

If your grid item heights are known or fixed ahead of time (as in this demo) and you want the resilience of a pure-CSS approach with graceful native upgrade as browser support grows, this pattern is a good fit. If your items load asynchronously with unknown, changing heights (like a photo grid where images load progressively), a JS-measured masonry library or a scroll reveal grid-style approach paired with ResizeObserver may still be more robust until native masonry support is universal. Pair this with CSS subgrid or container query units for more of the current native-CSS-layout toolkit.