CSS Grid Generator

Placing Items Without Fighting Line Numbers

• Click the cell instead of counting lines. Grid lines are numbered from the outside edge of the first track, not the first cell — off-by-one placement mistakes are the single most common grid bug, and clicking the target cell in the preview sidesteps counting entirely.
• Reach for span before a fixed end line. grid-column: 2 / span 3 keeps working if a column is added or removed later; grid-column: 2 / 5 quietly breaks the moment the grid's track count changes and line 5 no longer exists.
• Use repeat(auto-fill, minmax()) for anything that should reflow on its own. A card gallery or photo grid that needs more columns on a wide screen and fewer on a narrow one shouldn't need a media query at all — that's exactly the case auto-fill and minmax() together solve.
• Switch to named areas only once every item has an explicit position. An auto-placed item has no fixed cell for grid-template-areas to reference, so the export stays accurate only after every item's actual placement is set.

Features

A Grid Is Two Axes at Once, Which Is the Whole Point

Flexbox arranges items along a single line that can wrap; grid arranges them across rows and columns simultaneously, with both dimensions controllable from the same declaration. That's the entire reason grid-template-areas exists as a format: a string of quoted rows in the CSS itself ends up looking roughly like a diagram of the layout, which single-axis systems have no equivalent for since there's no second dimension to draw. The trade-off is that grid asks for more upfront decisions — how many columns, how many rows, how big each track is — before anything renders, where flexbox can often get away with just picking a direction and letting content dictate the rest.

This is also why grid and flexbox usually end up nested rather than competing in the same layout. A page's overall shell — header, sidebar, main content, footer — is a natural fit for grid, since all four regions need positioning relative to both rows and columns at once. What goes inside any single one of those regions — a horizontal row of buttons, a wrapping tag list, a form's label-and-input pairing — is a single-axis problem again, exactly what flexbox was built for. Reaching for grid everywhere, including places a single flex row would solve more simply, tends to produce more container and line-number bookkeeping than the layout actually needed.

fr Units Solve a Problem Percentages Never Could

A percentage-based column has to account for gaps and borders manually, because percentages are calculated against the full container width regardless of what else is eating into it — three columns at 33.33% plus two 16px gaps will overflow the container by exactly 32px. The fr unit sizes tracks against whatever space is actually left over after gaps, fixed-width tracks, and content-sized tracks are subtracted first, which is why repeat(3, 1fr) with a gap set produces three genuinely equal columns with correct spacing, no manual math required. Mixing fr with fixed units in the same track list — 200px 1fr 200px, the exact pattern behind the Holy Grail preset here — is how a layout gets a fixed-width sidebar and aside with a main column that absorbs every pixel of space neither of them needs.

What Auto-Placement Is Actually Doing

Any grid item without an explicit position doesn't just sit wherever — the browser runs a real algorithm, filling the grid's implicit row-by-row order and skipping any cell already occupied by an explicitly placed item. This is genuinely useful for a list of unknown length, like search results or a tag cloud, where forcing every item into a manually chosen cell would be pointless busywork. It stops being useful the moment layout meaning depends on a specific item sitting in a specific spot — a sidebar, a header, a footer — which is exactly the line between when auto-placement is the right default and when explicit placement (or a preset built around explicit placement, like Dashboard or Holy Grail) is worth the extra setup.

Gap Isn't a Margin With a Different Name

gap only ever adds space between tracks — it never adds space at the outer edge of the grid the way a margin on the first or last item would, and it never accumulates the way stacked margins on adjacent items can when two neighboring items both carry their own spacing. That's the entire reason gap replaced the old margin-based spacing hacks grid layouts used before it existed: a single column-gap and row-gap value on the container describes the whole grid's internal spacing in one place, instead of every item individually managing half of a shared gap and hoping the numbers line up with its neighbors. It also means resizing the gap later — going from a cramped 8px card grid to a roomier 24px one — is a single-value change instead of a find-and-replace across every item's margin declaration.

Reading a grid-template-areas Block Like a Floor Plan

Once every item has a real position, switching Export Named Areas on turns the numeric output into something closer to an actual floor plan of the page — each quoted row in the CSS is a visual row of the grid, and each word in it is the area occupying that cell, repeated across however many cells it spans. A stylesheet reader can look at the container rule alone and see the entire layout's shape without cross-referencing five separate .item-N blocks scattered elsewhere in the file, which is the practical reason larger teams tend to prefer named areas for page-level layouts even though line numbers are strictly more flexible for anything dynamic.

From a Clicked-Together Layout to Production CSS

A typical path: start from Dashboard or Holy Grail if the target layout is close to either, or build from Equal Columns for anything simpler, then click cells in the preview to move items around rather than typing line numbers by hand. Once the shape is right, deciding between line-number and named-area export usually comes down to whether the layout is fixed (areas read better) or dynamic with items whose count changes at runtime (line numbers, or auto-placement, handle that more gracefully). It's worth checking the preview at a narrower width too, since a fixed column count that looks right on a wide screen is the single most common reason a grid layout that tested fine on desktop breaks down on tablet — the Card Gallery preset's auto-fill approach exists specifically to avoid needing a separate mobile version of the same grid.

From there, the components sitting inside each grid area are a separate concern from the grid itself — the internal layout of a single card or nav bar is what flexbox handles, not grid, while a background or shadow on the grid items is exactly what the gradient generator and box shadow generator are for. Keeping the grid container, the item-level layout, and each item's visual styling as three separate, composable decisions — rather than trying to solve all three with one property — is generally what keeps a layout easy to adjust later instead of needing to be rebuilt from scratch.

Frequently Asked Questions