Most CSS layout articles stop at "Grid does rows and columns, Flexbox does one axis." That sentence is true and almost useless — it tells you nothing about the decisions you actually make in front of a real layout. This guide is the version I wish I'd had when I started shipping Grid in production: the mental model, the four or five properties that do 90% of the work, and the handful of traps that cost me afternoons of debugging so they don't cost you yours.
the mental model: tracks, lines, and cells
Before any property makes sense, you need three words. A track is a single row or column. A line is the divider between (and around) tracks — a grid with 3 columns has 4 vertical lines, numbered 1 through 4 from the start edge. A cell is the intersection of one row track and one column track. When you place an item, you are really saying "start at line X, end at line Y" in each direction. Almost every confusing Grid behaviour becomes obvious once you stop thinking in boxes and start thinking in lines.
defining the grid: columns, rows, and the fr unit
You turn an element into a grid container with display: grid and then describe its tracks. The unit you will use most is fr — a "fraction of the remaining free space." It is not a percentage: it is computed after fixed sizes, gaps, and content minimums are subtracted, which is exactly why it rarely overflows the way percentages do.
.layout {
display: grid;
grid-template-columns: 240px 1fr; /* fixed sidebar, fluid main */
grid-template-rows: auto 1fr auto; /* header, body, footer */
gap: 1.5rem; /* space between tracks */
min-height: 100vh;
}That single declaration is a full app shell: a 240px sidebar next to a column that absorbs everything else, with a header and footer that size to their content while the middle row stretches. No floats, no calc(), no magic numbers for the gutter.
placing items with line numbers and named lines
By default, items flow into cells in source order. To take control, address the lines directly. Raw numbers work, but they rot the moment you add a column. Naming your lines makes the intent survive refactors:
.layout {
grid-template-columns: [full-start] 240px [main-start] 1fr [full-end];
}
.hero {
grid-column: full-start / full-end; /* span the whole width */
}
.content {
grid-column: main-start / full-end; /* skip the sidebar */
}Negative line numbers are the other trick worth memorising: grid-column: 1 / -1 means "from the first line to the last line," i.e. span every column no matter how many there are. It is the most reliable way to make a row-spanning header that never needs updating.
grid-template-areas: the most readable layout you'll write
For page-level structure, named areas turn your CSS into ASCII art that a designer can read. You name regions, then draw them:
.page {
display: grid;
grid-template-columns: 240px 1fr;
grid-template-areas:
"sidebar header"
"sidebar main"
"sidebar footer";
}
.page > header { grid-area: header; }
.page > nav { grid-area: sidebar; }
.page > main { grid-area: main; }
.page > footer { grid-area: footer; }The payoff arrives at the breakpoint. To collapse the sidebar on mobile, you don't touch a single child — you redraw the map:
@media (max-width: 640px) {
.page {
grid-template-columns: 1fr;
grid-template-areas:
"header"
"main"
"sidebar"
"footer";
}
}responsive grids with no media queries: auto-fit vs auto-fill
This is the pattern people quote most and understand least. The classic "responsive card grid" is one line:
.cards {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
gap: 1rem;
}Cards are at least 250px wide, grow to share leftover space, and wrap to new rows on their own. But auto-fit and auto-fill are not interchangeable, and the difference is visible only when there are fewer items than fit in a row:
- auto-fill keeps the empty columns. Three cards in a five-wide grid render at their minimum size, with two ghost columns of empty space on the right.
- auto-fit collapses the empty columns to zero and lets the real cards expand to fill the row.
Rule of thumb: use auto-fit when you want items to stretch and fill the row (galleries, dashboards), and auto-fill when you want a stable column rhythm regardless of how many items exist (a catalogue that shouldn't reflow as stock changes).
the trap that will bite you: minmax(0, 1fr)
Here is the bug I see in almost every Grid codebase. You build a fluid column, drop a long unbroken string or a flex child inside it — a code block, a chart, a single 60-character URL — and instead of the column staying put, the whole layout blows past the viewport and a horizontal scrollbar appears.
The cause: an fr track has an implicit minimum size of auto, which means "at least as wide as my content's minimum." A non-wrapping child has a large minimum, so the track refuses to shrink below it. The fix is to override that floor explicitly:
grid-template-columns: 240px minmax(0, 1fr); /* not 240px 1fr */Reading it as "this column may shrink all the way to zero before its content forces it wider" is what finally made it click for me. If a Grid (or Flexbox) child is overflowing for no obvious reason, minmax(0, 1fr) — or min-width: 0 on the child — is almost always the answer.
subgrid: aligning nested content to the parent
Until recently, Grid had a real gap: a grid item that was itself a grid could not align its children to the parent's tracks. Card titles, bodies, and footers in a row would each align internally but drift out of sync with their neighbours. subgrid, now supported across all major browsers, fixes this:
.cards { display: grid; grid-template-columns: repeat(3, 1fr); gap: 1rem; }
.card {
display: grid;
grid-row: span 3;
grid-template-rows: subgrid; /* inherit the row lines from .cards */
}Now every card's title, body, and footer line up across the whole row even when the text lengths differ — the kind of pixel-level consistency that used to require fixed heights or JavaScript.
grid vs flexbox: a decision you can make in one question
They are not rivals; production layouts use both, often nested. The honest decision rule is shorter than the debates around it:
- Reach for Grid when the container defines the structure — you know the rows and columns up front and you want children to land in a fixed scaffold. Page shells, dashboards, image galleries, any "align across rows" requirement.
- Reach for Flexbox when the content defines the structure — a row of items of unknown number and width that should distribute and wrap based on their own size. Toolbars, tag lists, button groups, nav bars.
A useful tell: if you find yourself fighting Flexbox with fixed widths and margins to force alignment between separate rows, you wanted Grid. If you're computing column counts in Grid to handle a variable number of small items, you probably wanted Flexbox.
the accessibility caveat nobody mentions
Grid lets you place items visually in any order regardless of their position in the HTML. That power is a footgun: order, grid-row, and grid-column change only the visual order, not the DOM order. Keyboard focus and screen-reader narration still follow the source. If you visually move your primary call-to-action above the navigation but leave it last in the markup, a keyboard user reaches it last. Keep the DOM order logical and use Grid for visual polish, not to paper over markup you should fix.
when not to reach for grid
Grid is not free of cost. For a single row of three buttons, display: flex; gap: .5rem is simpler and conveys intent better than a one-row grid. For long-form article text, normal block flow with a max-width is more robust than any grid. And for truly content-driven masonry layouts (Pinterest-style), Grid's row model still struggles — the emerging masonry value isn't broadly shippable yet, so a small JS library or columns layout remains the pragmatic choice. Use the simplest tool that holds, and let the complexity of the layout — not novelty — pull you toward Grid.
conclusion
CSS Grid earns its reputation not because it can do everything, but because it makes two-dimensional intent declarative: you describe the scaffold once and the browser does the placement, the wrapping, and the responsive reflow. Learn the line-based model, lean on fr and named areas, keep minmax(0, 1fr) in your back pocket for overflow, and respect DOM order for accessibility. Do that and you'll spend your time deciding what the layout should be, not wrestling the CSS into letting you build it.