Flexbox vs Grid — When to Use Each

One-Dimensional vs Two-Dimensional — Not "Old vs New"

The most common mistake engineers make when choosing between Flexbox and Grid is treating it as a question of which one is "better" or "more modern" — Grid arrived after Flexbox in the CSS specification timeline, which quietly leads people to assume it must be the upgrade. That framing is wrong, and it produces genuinely worse layouts. The real decision axis has nothing to do with age: it is whether the content you are laying out is fundamentally one-dimensional or two-dimensional.

A one-dimensional layout is a single row or a single column of items, where you care about how they distribute themselves along one axis — and you are usually fine letting each item's own content determine its size. A two-dimensional layout is a genuine grid of rows and columns simultaneously, where you want content to line up against a shared set of both row boundaries and column boundaries at once. Flexbox was built for the first kind. Grid was built for the second. Neither is a strictly more powerful version of the other — they model different shapes of problem.

Do I actually care about alignment across BOTH rows and columns
at the same time?

  NO  → it's a single row or column of items → Flexbox
  YES → items need to line up on a shared grid in two directions → Grid

Why this distinction is more useful than a feature checklist

Tutorials that compare Flexbox and Grid feature-by-feature (both have gap, both have alignment properties, both can wrap) tend to make the two look nearly interchangeable, which is exactly backwards from how the decision should actually be made in practice. The feature overlap is real, but it is also mostly beside the point — the decision that actually matters is made before any property is written, at the moment you decide what shape the content naturally is.

Concrete Scenarios Where Flexbox Is the Obviously Correct Choice

These are not "Flexbox can technically also do this" cases — they are cases where Flexbox is the more natural, less code, more maintainable choice, because the content is genuinely one-dimensional and should size itself based on its own content rather than fixed tracks.

.navbar {
  display: flex;
  align-items: center;
  justify-content: space-between;
  padding: 16px 24px;
}
/* Logo on the left, nav links in the middle, a "Sign in" button on the
   right — a single row, each item sized to its own content. Building
   this with Grid would mean pre-defining column widths for content
   (a logo, a variable number of nav links) that has no natural fixed width. */

.toolbar {
  display: flex;
  gap: 8px;
}
.toolbar button {
  padding: 8px 16px;
  white-space: nowrap;
}
/* "Save" and "Save and Publish" naturally need different widths.
   Flexbox gives each button exactly the width its label needs — a Grid
   with a fixed column-per-button would either clip the longer label
   or waste space around the shorter one. */

.modal-overlay {
  display: flex;
  align-items: center;
  justify-content: center;
  min-height: 100vh;
}
/* Perfectly centers one child both ways. Grid can do this too (place-items:
   center), and either is genuinely fine here — but centering a single item
   is about as one-dimensional a problem as CSS layout has. */

The common thread across all three: the number of items is either variable or the exact sizes are meant to come from the content itself, not from a predefined structure. That is the signature of a Flexbox problem.

flex-wrap — where Flexbox starts to look two-dimensional, and why it still isn't

flex-wrap: wrap lets flex items spill onto multiple lines, which can visually look like a grid — but it is important to understand this is still fundamentally one-dimensional layout logic, just repeated across several lines independently. Each wrapped line manages its own sizing separately; items in one row do not line up with items in the row above unless every row happens to contain identically-sized items by coincidence.

.flex-wrap-demo {
  display: flex;
  flex-wrap: wrap;
  gap: 12px;
}
/* Items with DIFFERENT content lengths on row 1 will size that row's
   items independently from row 2's items — there is no shared column
   grid tying "item 2 on row 1" to "item 2 on row 2." If your design
   actually needs that alignment, that need itself is the signal you
   want Grid, not wrapped Flexbox. */

Concrete Scenarios Where Grid Is the Obviously Correct Choice

Grid wins precisely where the previous section's Flexbox cases stop applying: when alignment needs to hold across both rows and columns simultaneously, or when the layout is defined by an explicit structure rather than by the content's own natural size.

body {
  display: grid;
  grid-template-columns: 240px 1fr;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "header header"
    "sidebar content"
    "footer footer";
  min-height: 100vh;
}
/* This is genuinely two-dimensional: the sidebar's height must match
   the content area's height (same row), while ALSO having an
   independent, fixed column width from it. Flexbox has no direct way
   to express "these two siblings share a row's height but not a
   column's width" without extra wrapper elements and workarounds. */

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
  gap: 20px;
}
/* Every card in column 2 lines up with the LEFT EDGE of every other
   card in column 2, across every row — a genuine two-dimensional
   alignment guarantee that wrapped Flexbox does not provide. */

.widgets {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-auto-rows: 160px;
  gap: 20px;
}
.widget-featured {
  grid-column: span 2;
  grid-row: span 2;
}
/* A widget that spans 2 columns AND 2 rows, sitting flush against its
   neighbors on all sides, is a two-dimensional placement problem by
   definition — this has no clean Flexbox equivalent at all. */

The pattern across all three: something needs to line up along two independent axes at once — a shared row height combined with an independent column width, or a card grid where both rows and columns stay aligned, or a widget that spans real, defined space in both directions. That two-axis alignment requirement is the unambiguous signal for Grid.

Grid for the Page Shell, Flexbox for the Component Internals

Real production pages very rarely pick one system exclusively — the dominant real-world pattern is Grid for the overall page structure, and Flexbox for the internals of individual components placed inside that structure. This is not a compromise or a sign of indecision; it is the correct application of the one-dimensional/two-dimensional distinction at two different scales of the same page.

<div class="page">
  <header class="page-header">Site Header</header>
  <main class="product-grid">
    <article class="product-card">...</article>
    <article class="product-card">...</article>
    <article class="product-card">...</article>
  </main>
</div>

.page {
  display: grid;                 /* GRID — page-level, two-dimensional structure */
  grid-template-rows: auto 1fr;
  min-height: 100vh;
}

.product-grid {
  display: grid;                 /* GRID — a genuine two-dimensional card grid */
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 24px;
  padding: 24px;
}

.product-card {
  display: flex;                 /* FLEXBOX — one-dimensional internal stacking */
  flex-direction: column;
  justify-content: space-between;
  padding: 16px;
  border: 1px solid var(--border);
  border-radius: 10px;
}

.product-card .price-row {
  display: flex;                 /* FLEXBOX — a single row: price on the left,
                                     an "Add to cart" button on the right */
  justify-content: space-between;
  align-items: center;
}

Notice the reasoning at each level. The outer .page is Grid because the header and main content area are a genuine two-dimensional structure. The .product-grid is Grid because cards need to align in both rows and columns as their count grows. But .product-card itself switches to Flexbox, because its internal content — an image, a title, a description, a price row — is a single vertical stack, one-dimensional by nature, where each piece should size to its own content rather than snap to a predefined track. And .price-row, nested one level deeper still, is Flexbox again for the same reason: a single row, two items, distributed with space-between.

A Second Mental Model, for the Genuinely Ambiguous Cases

The one-dimensional/two-dimensional test resolves most real decisions, but a smaller set of layouts sit genuinely on the boundary — a simple 3-column row of equal-width cards, for instance, could reasonably be built either way. For those cases, a second, complementary question helps: should the layout be driven by the content's own size ("content-out"), or by explicit tracks you define regardless of content ("layout-in")?

.tag-list {
  display: flex;
  flex-wrap: wrap;
  gap: 8px;
}
/* Each tag is exactly as wide as its own label. The LAYOUT is a
   consequence of the content — there is no predefined tag width
   anywhere in this CSS. */

.stat-tiles {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  gap: 16px;
}
/* Four EQUAL columns, defined explicitly, regardless of whether one
   tile's number happens to be longer than another's. The CONTENT
   fits into a predefined structure, not the other way around. */

This framing is why flex-grow/flex-shrink/flex-basis exist as a trio in the first place — they are Flexbox's mechanism for negotiating exactly how much an item should be allowed to deviate from its own natural, content-driven size. Grid has no real equivalent negotiation, because Grid tracks are not meant to be primarily content-driven in the first place — 1fr, minmax(), and fixed pixel tracks are all ways of defining the structure up front, with content simply filling whatever space that structure allocates.

Layouts Where Either Genuinely Works — And How to Pick Anyway

A small set of common layouts sit close enough to the boundary that both systems produce a reasonable result. Rather than treat these as a coin flip, it is worth having a specific, repeatable tiebreaker for each.

/* Flexbox version */
.columns { display: flex; gap: 20px; }
.columns > * { flex: 1; }

/* Grid version */
.columns { display: grid; grid-template-columns: repeat(3, 1fr); gap: 20px; }

Tiebreaker: if the number of columns is genuinely fixed and will not change, either is fine — Grid's version arguably documents the intent ("exactly 3 equal tracks") slightly more directly. If there is any chance the column count needs to become responsive later (2 columns on tablet, 1 on mobile), lean Grid now, since grid-template-columns is the property you would be redeclaring in a media query anyway — starting there avoids a rewrite from Flexbox to Grid later.

/* Flexbox */
.center { display: flex; align-items: center; justify-content: center; }

/* Grid */
.center { display: grid; place-items: center; }

Tiebreaker: purely a matter of what is already the dominant layout system in the surrounding code. If the parent element is already display: flex for other reasons, do not introduce Grid just to center one child — use margin: auto on the child instead, which works inside an existing flex container without changing the container's display type at all.

Why the Right Choice Up Front Saves a Real Rewrite Later

The cost of picking the wrong system rarely shows up on day one — a Flexbox layout used where Grid belonged, or vice versa, usually still renders correctly at first. The cost shows up later, when a requirement changes in a direction the wrong system does not naturally support, and the fix becomes a genuine restructuring rather than a small edit.

.product-list {
  display: flex;
  flex-wrap: wrap;
  gap: 20px;
}
.product-card {
  flex: 1 1 240px;
}
/* Works fine at first. Then a request comes in: "make the 3rd product
   in every row of 4 span 2 columns, to feature it." Flexbox has no
   direct way to say "this item spans 2 tracks and every other item
   still lines up in a shared column grid" — because there IS no
   shared column grid in Flexbox, by design. */

.product-list {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 20px;
}
.product-card.featured {
  grid-column: span 2;   /* one line — no restructuring needed */
}

This is not a claim that Grid should be the default for every card list "just in case" — that would be over-engineering against a requirement that may never arrive. It is a specific argument for the earlier heuristic: if a layout involves items that visually need to line up in a shared row-and-column structure (even if every item is currently the same size), that structural relationship is real today, whether or not any single item currently spans more than one track. Picking Grid there is choosing the tool that already matches the actual shape of the problem, not preemptively solving a hypothetical future one.

A Layout Review at a Chicago Fintech Startup

.transaction-row {
  display: flex;
  justify-content: space-between;
  padding: 12px 0;
}
.transaction-row .merchant-info {
  display: flex;
  flex-direction: column;
}
/* Each row: merchant name + date stacked on the left (flex column),
   category tag and amount spaced out on the right. Works — until
   the reviewer opens it next to 50 real transaction rows. */

.transaction-list {
  display: grid;
  grid-template-columns: 2fr 1fr 1fr 1fr;   /* merchant, date, category, amount */
  row-gap: 4px;
}

.transaction-row {
  display: contents;   /* each row's own elements become direct grid items,
                           so they align against the SAME shared columns */
}

.transaction-row .merchant  { grid-column: 1; }
.transaction-row .date      { grid-column: 2; }
.transaction-row .category  { grid-column: 3; }
.transaction-row .amount    { grid-column: 4; text-align: right; }

Four Misconceptions About Choosing Between Flexbox and Grid

5 Interview Questions — With Complete Answers

Flexbox/Grid Decision Mistakes Beginners Make Constantly

.page-shell {
  display: flex;
  flex-direction: column;
}
.body-row {
  display: flex;
}
.sidebar { width: 240px; }
.content { flex: 1; }
/* Two nested Flexbox containers, standing in for what is
   actually a simple 2-column, 3-row Grid structure */

.page-shell {
  display: grid;
  grid-template-columns: 240px 1fr;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "header header"
    "sidebar content"
    "footer footer";
}

.card-grid {
  display: flex;
  flex-wrap: wrap;
}
.card {
  width: 240px;   /* manually fixed width, to fake grid-like columns */
  margin: 10px;   /* margin, not gap — extra edge space around the grid */
}

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 20px;
}

.toolbar {
  display: grid;
  grid-template-columns: repeat(5, auto);  /* Grid, for 5 buttons that just need to sit in a row */
}

.toolbar {
  display: flex;
  gap: 8px;
}

Rendering Bugs From Picking the Wrong Layout System — And Exactly Why