CSS Grid Generator

Build grid-template-columns, grid-template-rows and grid-template-areas visually — drag, paint cells, and copy the live CSS.

Everything happens locally in your browser. Nothing ever leaves your device.

Generated CSS

How It Works

The grid tab builds track lists from your counts and sizes: three 1fr columns become grid-template-columns: repeat(3, 1fr), the shorthand that expands to one fraction of free space per column. auto sizes a track to its content, and a fixed px value reserves exactly that width — a common recipe is one fixed sidebar track plus a fluid 1fr track. If you want a track that flexes with limits, hand-edit the output into minmax(80px, 1fr), which this builder deliberately keeps out of the shorthand so the generated CSS stays readable.

The fr unit
An fr is one share of the space left after fixed-size tracks, gaps and padding are subtracted — free space, not a percentage. That distinction matters: with a 200px sidebar, gap 16px and two 1fr columns, each fr gets (width − 216px) ÷ 2. Two tracks at 2fr 1fr split the same remainder 2:1, and an fr never causes overflow the way percentages can when you forget the gaps.
grid-template-areas naming rules
Every quoted string is one row; each token is one cell, and tokens must line up in count across rows. A named area must form a perfect rectangle — an L-shaped region is invalid and, honestly, the browser discards the whole grid-template-areas declaration when any name breaks the rule, so the warning line above is not cosmetic. Empty cells use the dot character. Once painted, each item can grab an area by name instead of counting start/end lines.
Implicit vs explicit tracks
You declare the explicit grid — the tracks in grid-template-columns and -rows. Content beyond it (more items than cells, or an area grid plus unassigned items) creates implicit tracks outside the template, sized by grid-auto-columns/-rows, which default to auto. That is why a demo that looks like it has extra mystery rows usually just overflowed the explicit grid.

Frequently Asked Questions

Grid or flexbox — which one when?

Think of grid as layout-first and flex as content-first. If you are drawing a two-dimensional skeleton — columns and rows that should line up across the page — use grid, because tracks align on both axes. If you are distributing a row of buttons, chips or nav links whose sizes come from their content, flex is lighter. Real pages mix them: grid for the page shell, flex inside each cell.

Can I use subgrid with this layout?

subgrid lets a nested grid borrow tracks from its parent — handy for card rows whose inner labels must align. Support is genuinely mainstream now: Firefox had it in version 71 (2019), Safari in 16 (2022) and Chrome in 117 (2023), so it counts as broadly available in 2026. This generator stays on top-level grid because subgrid needs real nesting to demonstrate honestly.

What about old Internet Explorer?

IE 10/11 implemented an entirely different, prefixed spec (-ms-grid) with a different auto-placement model, and this tool does not output it. It also cannot polyfill faithfully. If you must support that IE, float or flexbox fallbacks inside @supports (display: grid) are the pragmatic route — otherwise ignore IE.

Where do items without a grid-area end up?

They keep auto-placement and fill the cells that no named area covers — which, in a fully painted 4×4 template, means the browser appends them as implicit rows below the grid. Assign an area to every visible item, or leave the template unpainted, if you want the compact demo to look intentional.

Is anything uploaded to a server?

No. The painter, the track math and the CSS output all run in your browser as plain JavaScript and CSS. Your grid layout is never stored, sent or fetched, and the page works with the network switched off.