CSS grid lanes bring native masonry to the web

For more than a decade, creating Pinterest‑style “waterfall” layouts on the web has meant reaching for JavaScript plugins, complex hacks, or both. While CSS Grid revolutionized two‑dimensional layout, it stopped short of offering a true masonry mode where items neatly pack into columns without leaving awkward gaps. That gap is finally closing.

With the arrival of CSS Grid Lanes, first landing in Safari Technology Preview 234 and already prototyped in Chrome and Firefox, the platform is gaining a native, standardized way to build masonry experiences in pure CSS. Grid Lanes builds directly on top of the existing Grid mental model and syntax, while giving the browser a new instruction: flow items in lanes and pack them like a waterfall, instead of aligning them on rows. In this article, we will look at what CSS Grid Lanes are, how they differ from earlier proposals, how to use them today, and what they mean for performance, accessibility, and the future of layout on the web.

From JavaScript Masonry to Native CSS

Historically, “masonry layout” on the web has been synonymous with JavaScript libraries. The classic Masonry.js script clocks in at around 24 kB, and even newer “Masonry Grid” implementations still add roughly 1.4 kB of JavaScript to a page. These libraries measure the height of each card, compute where it should go, and then position everything with manual layout logic. The result looks great, but it comes with runtime cost, added complexity, and potential jank as layouts recalculate on resize.

Documentation like MDN’s “Masonry layout” guide has long described the effect developers were aiming for: one axis behaves like a regular grid, while the other uses a masonry algorithm that allows items to “rise up to completely fill the gaps.” In practice, though, authors had to re‑implement that algorithm in their own JavaScript, ship extra code, and maintain custom logic across browsers and devices.

CSS Grid Lanes changes this equation by making masonry a first‑class layout capability of the browser itself. Instead of pushing layout decisions into JavaScript, where they compete with other main‑thread work, Grid Lanes pushes the masonry algorithm into the rendering engine. The result is zero kilobytes of extra script, simpler CSS, and a model that can be standardized and optimized by browser vendors over time.

How CSS Grid Lanes Work

CSS Grid Lanes introduces a new display value: grid-lanes. The core idea is refreshingly simple. You keep using familiar Grid properties, such as grid-template-columns, gap, and auto-fill, but you tell the browser to lay items out in lanes rather than honoring strict row tracks. WebKit describes the behavior as “do not create rows, instead pack the content into a masonry/waterfall‑like pattern.”

At a high level, you can think of lanes as vertical “stacks” into which items are placed, one after another, always trying to fill the smallest current stack first. This is similar to what many JavaScript libraries do, but now the algorithm and its edge cases are handled natively by the browser. The API surface stays small, and most of your existing Grid knowledge carries over directly.

A minimal Grid Lanes setup looks like this:

<style>
.container {
display: grid-lanes;
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
gap: 16px;
}
</style>

display: grid-lanes; switches the grid into masonry mode; grid-template-columns still controls how many columns you can fit and how they stretch, and gap still determines the spacing between items. There is no need to define row tracks or specify grid-template-rows: masonry, the lanes algorithm takes over the vertical flow.

From grid-template-rows: masonry to Lanes

Grid Lanes did not appear out of nowhere. The CSS Grid Layout Level 3 work on masonry has been ongoing for years, with earlier drafts proposing syntax like grid-template-rows: masonry and grid-template-columns: masonry. Firefox implemented an early prototype behind a flag using this approach, and WebKit experimented with similar syntax in their “Help us invent masonry layouts” call for feedback.

Those experiments were crucial in shaping the final design. They validated that authors wanted native masonry, but they also surfaced complexities, such as how masonry should interact with explicit tracks, subgrid, and auto‑placement rules. The CSS Working Group spent multiple years debating these trade‑offs, collecting feedback from implementers, and testing interoperability concerns.

By early 2025, the group converged on a lanes‑based model exposed via display: grid-lanes, reusing as much of the existing Grid mental model as possible. This direction unified vendors around a single, more composable syntax. WebKit’s December 2025 announcement explicitly calls Grid Lanes “the future of masonry layouts on the web,” and the masonry section of the CSS Grid Layout Level 3 Editor’s Draft now reflects this lanes‑based approach. MDN still documents grid-template-rows: masonry as experimental, but that content is tracking the evolving drafts and notes that behavior and syntax are in flux.

Browser Support in Late 2025

As of December 2025, Safari Technology Preview 234 is the first browser build to ship a working implementation of CSS Grid Lanes. Developers using the Safari TP can already build Pinterest‑style galleries using nothing more than display: grid-lanes, grid column definitions, and gap. This is a major milestone: for the first time, a mainstream engine has a shipping, standards‑aligned masonry mode.

Chrome is not far behind. Version 140 includes an experimental Grid Lanes implementation behind a flag, following the same design direction agreed on in the CSS Working Group. Articles summarizing the WG outcome note that Chrome’s implementation is in progress, with production rollout expected later, likely sometime in 2026 or beyond, once the spec stabilizes and interoperability testing progresses.

Firefox played a pioneering role by shipping the early grid-template-rows: masonry prototype behind a flag, and that work informed the final lanes design. While Firefox has not yet shipped display: grid-lanes by default, its earlier involvement means it is well‑positioned to adopt the standardized model. For now, MDN marks masonry as experimental and warns that developers should carefully check compatibility before relying on it in production, using progressive enhancement strategies instead of assuming universal support.

Authoring Patterns and Progressive Enhancement

Because masonry via Grid Lanes is still rolling out, the recommended way to use it in real projects is as a progressive enhancement. You start with a robust fallback, often a regular CSS Grid layout with equal‑height rows or a multi‑column layout, and then opt into display: grid-lanes only when the browser supports it. This approach keeps your site usable everywhere while giving capable browsers a richer experience.

A typical pattern uses a feature query via @supports:

.gallery {
display: grid;
grid-template-columns: repeat(4, 1fr);
gap: 8px;
}

@supports (display: grid-lanes) {
.gallery {
display: grid-lanes;
}
}

In this example, browsers that do not understand display: grid-lanes simply ignore the @supports block and fall back to a standard Grid layout. Browsers that do support lanes automatically upgrade to masonry behavior, without any additional JavaScript. This same style of feature detection has already been recommended in tutorials covering grid-template-rows: masonry, and it maps neatly to the new lanes API.

Performance and Maintainability Benefits

Moving masonry logic from JavaScript to native CSS has a direct and measurable impact on performance and maintainability. Where legacy solutions would ask you to ship tens of kilobytes of layout logic, Grid Lanes adds exactly zero kilobytes of JavaScript. The layout computations live inside the browser engine, alongside existing layout and painting phases that are already highly optimized in C++.

This shift means less JavaScript to parse, compile, and execute, which is especially important on low‑power devices and constrained networks. It also reduces the risk of layout thrashing or forced synchronous reflows that can occur when JavaScript manipulates layout in response to resize events. The browser can schedule masonry calculations intelligently alongside other rendering work, improving smoothness and responsiveness.

Maintainability improves as well. Instead of binding, configuring, and debugging third‑party plugins, authors can express intent declaratively in CSS. The behavior is documented in the CSS Grid Layout Level 3 spec, and differences between browsers are handled through standardization and test suites rather than ad hoc polyfills. Community commentary has already started framing Grid Lanes as “killing” the need for heavy masonry libraries; while JavaScript will remain useful for legacy support and advanced custom behaviors, the default for modern sites will increasingly be native CSS.

Accessibility and Ordering Considerations

While masonry layouts are visually appealing, they come with non‑trivial accessibility concerns. MDN and independent blog posts have long pointed out that automatic masonry placement can produce a visual order that differs from the DOM source order. Keyboard users and assistive technologies generally follow the document order, so if items appear “above” others visually but come later in the markup, the reading and tabbing experience can become confusing.

Earlier drafts of CSS masonry introduced properties like masonry-auto-flow to give authors some control over how items are placed into columns and rows, with the goal of mitigating tab order issues. Those same concerns are now an active part of the Grid Lanes design discussions. Any native masonry solution must balance the desire for optimal packing against the need to preserve predictable navigation and reading flows.

For now, best practice remains the same: treat the DOM order as the canonical reading order, and use masonry as a purely visual enhancement. Do not rely on masonry placement to convey relationships, sequence, or hierarchy that are not also reflected in the markup. As Grid Lanes matures, expect more guidance and possibly new controls to help authors align visual and logical order in accessible ways.

Practical Use Cases for Grid Lanes

Grid Lanes is particularly well‑suited to content collections where item heights are inherently variable: image galleries, card‑based article grids, product listings with different titles and descriptions, or mixed‑media dashboards. In all of these scenarios, a strict row‑based grid can leave awkward gaps, especially on wider screens or when content lengths vary significantly.

With traditional Grid, you might attempt to normalize heights or truncate content to keep rows aligned, but that often means sacrificing flexibility and readability. Masonry layouts embrace variability by letting shorter items “rise up” under taller neighbors, fully using the vertical space. This is exactly the layout pattern MDN describes, and it’s the behavior that Grid Lanes now supports natively.

Because the syntax piggybacks on existing Grid properties, teams that already use Grid can adopt lanes incrementally. You can start with a standard grid component, then add a feature query to enable display: grid-lanes in browsers that support it. Over time, design systems can expose both “grid” and “masonry grid” variants with minimal additional CSS and no additional JavaScript.

CSS Grid Lanes marks a turning point for masonry layouts on the web. After years of experimentation with grid-template-rows: masonry, prototypes in Firefox, and spirited debate in the CSS Working Group, the platform now has a clear, shared path forward. WebKit’s implementation in Safari Technology Preview 234 and Chrome’s prototype in version 140 show that vendors are rallying around the lanes model, and the CSS Grid Layout Level 3 Editor’s Draft is converging on a standardized masonry story.

In the near term, masonry remains an enhancement rather than a baseline feature. MDN and contemporary tutorials still classify it as experimental and “not production‑ready” across all browsers, urging robust fallbacks and progressive enhancement. But the trajectory is clear: as Grid Lanes ships broadly, many sites that once depended on Masonry.js and its descendants will be able to drop that JavaScript entirely. Native CSS masonry will become the default way to build visually rich, packed grids, lighter, faster, and more maintainable than what came before, and deeply integrated into the fabric of the web platform.