CSS Grid vs Flexbox: A Decision Guide With Real Layouts

A client site we inherited last year had a 240-line stylesheet for one card grid. Four media queries, percentage widths with calc() subtracting margin, a :nth-child(3n) rule to kill the right margin, and a separate override because the last row with two items looked wrong. The replacement was four lines of CSS Grid. It handled every breakpoint, including the ones the original never accounted for.

That’s the practical shape of the css grid vs flexbox question in 2026. Both are universally supported, both have gap, both do alignment properly. The decision isn’t about capability any more. It’s about which one makes the next change cheap, and most teams still reach for flexbox out of muscle memory when grid would have ended the conversation.

Here’s the decision framework we actually use, with the layouts, the gotchas, and the cases where grid is the wrong call.

The distinction that actually predicts the right answer

Forget “one dimension versus two dimensions”. It’s technically true and practically useless, because every flex row with flex-wrap: wrap looks two-dimensional on screen.

The useful framing is content-out versus layout-in. Flexbox asks each item how big it wants to be, then distributes the leftover space according to flex-grow, flex-shrink and flex-basis. The container reacts to the content. Grid does the opposite: you declare the tracks, then items land in them. The content reacts to the container.

That single difference explains the wrapped-flex problem. When flex items wrap, each row calculates its own distribution independently. Row one has three items and divides the space three ways. Row two has two items and stretches them. There is no mechanism for row two to know what row one did. Grid rows share column tracks by definition, so alignment is free.

The question to ask is: do items in different rows need to line up with each other? If yes, grid. If no, flexbox is usually simpler and less code.

css grid vs flexbox: a five-second decision test

Run these in order and stop at the first yes.

1. Is it a single row or column of things sized by their own content? Nav bar, toolbar, button group, form row, tag list, inline metadata. Flexbox. Don’t overthink it.
2. Do items need to align across both axes? Card grids, dashboards, pricing tables, media galleries, footers with four columns of links. Grid.
3. Is the item count fixed and known at build time? Grid with named areas, because the layout becomes readable in the CSS rather than guessable from the markup.
4. Is the item count arbitrary and user-generated? Grid with auto-fit if you want equal tracks, flexbox if items should keep their natural widths and wrap raggedly.
5. Are you centring exactly one thing? Either. display: grid; place-items: center is the shortest. Since 2024, align-content: center works in plain block layout across all engines, so you may not need a formatting context at all.

Layout 1: the card grid with no media queries

This is the layout that converts people. Any number of cards, any viewport, no breakpoints.

.card-grid {
  display: grid;
  / min() stops the 18rem minimum from overflowing a 320px viewport /
  grid-template-columns: repeat(auto-fit, minmax(min(18rem, 100%), 1fr));
  gap: var(--space-6, 1.5rem);
}

The trap nobody mentions: auto-fit collapses empty tracks, so if the grid only ever contains two cards on a 1600px display, those two cards become 760px monsters. auto-fill keeps the empty tracks and the cards stay a sane width, but then you get a ragged left-aligned row. Pick based on the real content, not the demo.

When you want cards that never exceed a sensible width but still centre as a group:

.card-grid--capped {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(18rem, 24rem));
  justify-content: center;
  gap: 1.5rem;
}

Using a token for gap rather than a hard-coded value matters more than it looks, because gap is the one spacing value that appears in every layout you write. We cover that system in design tokens for small teams.

Why the flexbox version is worse

The flex equivalent needs flex: 1 1 18rem on each child, which works until the last row, where two items stretch to fill the width and look nothing like the rows above. The common fix is appending invisible filler elements. If you’ve ever shipped <li class="card card--ghost"></li>, you already know grid was the answer.

Layout 2: the page shell, where named areas earn their keep

Header, sidebar, main, footer. Grid’s advantage here isn’t the output, it’s that the CSS is a picture of the layout.

.app {
  display: grid;
  min-height: 100svh; / svh, not vh: avoids the mobile URL-bar jump /
  grid-template-rows: auto 1fr auto;
  / minmax(0, ...) so a wide table in main can't push the sidebar off-screen /
  grid-template-columns: minmax(0, 16rem) minmax(0, 1fr);
  grid-template-areas:
    "header  header"
    "sidebar main"
    "footer  footer";
}

.app > header { grid-area: header; }
.app > aside  { grid-area: sidebar; }
.app > main   { grid-area: main; }
.app > footer { grid-area: footer; }

@media (max-width: 48rem) {
  .app {
    grid-template-columns: minmax(0, 1fr);
    grid-template-areas:
      "header"
      "main"
      "sidebar"
      "footer";
  }
}

Two things worth noting. The sidebar moves below main on mobile without touching the DOM order, which keeps the tab order reading header, main content, then supplementary navigation. That’s usually the accessible order anyway, but verify it. Reordering content visually away from DOM order is one of the easiest ways to break keyboard navigation.

Named areas also respect direction: rtl automatically. The columns swap because the inline axis flips. If you’re building anything that ships in Arabic or Hebrew, grid saves you an entire RTL override sheet. This is one reason the RTL demos in Canvas lean on grid for page structure even though the component layer stays on Bootstrap 5 flex utilities.

Layout 3: toolbars and anything content-sized

Grid is wrong here, and people still force it. A toolbar has buttons of unpredictable width, possibly a search field, possibly a right-aligned group. Flexbox handles it in four declarations.

.toolbar {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: 0.75rem;
}

.toolbar__search { flex: 1 1 12rem; min-width: 0; }

/ Pushes everything after it to the far end, and flips correctly in RTL /
.toolbar__end { margin-inline-start: auto; }

margin-inline-start: auto instead of margin-left: auto is a one-character-per-rule change that removes an entire class of RTL bug. We’ve stopped writing the physical version entirely.

The min-width: 0 on the search field is not optional. Flex items have min-width: auto by default, meaning they refuse to shrink below their content’s minimum size. A long placeholder, a <pre> block or an unbroken URL will blow the container out horizontally and produce the mystery page-wide scrollbar you’ll spend twenty minutes bisecting.

Subgrid: the feature that made card alignment trivial

Cards with titles of different lengths used to need fixed heights or JavaScript. Subgrid fixed it. It’s been available in Firefox since 71, Safari since 16 and Chrome since 117, so there’s no reason to avoid it in 2026 unless you still support a browser that stopped getting security updates years ago.

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(18rem, 100%), 1fr));
  gap: 1.5rem;
}

.card {
  / Occupy three implicit row tracks and adopt them as the card's own rows /
  grid-row: span 3;
  display: grid;
  grid-template-rows: subgrid;
  gap: 0.75rem;
}

With that, every card’s heading occupies row one, body row two, CTA row three, and all three align horizontally across the row regardless of content length. No fixed heights, no line-clamp hacks, no equal-height script. The only constraint is that the number of rows a card spans must match the number of elements it contains, so irregular cards need a placeholder element or an explicit grid-row.

If you’re rebuilding a case-studies index or a services grid, this is where to start. It’s one of the items on our portfolio site checklist that teams reliably skip.

The four bugs that cost us the most hours

• 1fr is not minmax(0, 1fr). 1fr expands to minmax(auto, 1fr), so a track containing a wide table or a long string will refuse to shrink. Any grid that holds unpredictable content should use minmax(0, 1fr). This single change fixes most “my grid overflows on mobile” reports.
• Flex item min-width: auto. Same symptom, different mechanism. Covered above, and worth adding to a base layer: .flex > * { min-width: 0; } is a defensible default in a design system.
• auto-fit with few items. Collapsed tracks make two cards fill a 1600px row. Switch to auto-fill or cap the track with a max value.
• grid-auto-flow: dense on long lists. Dense packing rescans earlier tracks for each placement, so the cost grows with list length. It also reorders items relative to DOM order, which breaks the reading order for screen readers and the tab order for anything focusable. Fine for a 20-item masonry-ish gallery, bad for an infinite feed. Profile it in the DevTools Performance panel and look at the Layout entries before and after, not at a vibe.

Where neither one is the right tool

True masonry, the Pinterest layout with variable-height items and no row alignment, still has no settled CSS answer. The standards work split into two competing proposals: a masonry value for grid-template-rows and a more general item-flow syntax. That disagreement is why it hasn’t landed as a stable cross-browser feature. Check current support before you commit. For production today, a small JS library or a column-based approximation with column-count remains the safe choice, accepting that column-count orders items top-to-bottom within each column rather than left-to-right.

Tabular data belongs in a <table>. Grid can replicate the look, and people do it to get better responsive control, but you lose the row and column semantics that screen readers announce. If you must, apply display: grid to the table itself and set the appropriate ARIA roles back, and test it with a real screen reader before shipping.

Text flow around an image is float, still, in 2026. It’s the one job floats were designed for and they do it correctly.