A grid is not decoration. It is the set of invisible rules that decide where things on a page are allowed to sit, and how those positions hold together as the screen changes size. Most layouts that feel slightly wrong are not ugly. They are ungoverned.
This is a build guide, not a history of Swiss typography. We cover what a grid actually is, how to choose its parts, how it behaves across breakpoints, and when to break it on purpose. Practical defaults where they earn their place.
What a grid system actually is
A grid system is four decisions, not one: the number of columns, the gutter between them, the margin at the edges, and the maximum width of the field they live in. Everything else is arrangement. A “12-column grid” tells you almost nothing until you also know the gutter, the margins, and where the whole thing stops growing.
It helps to separate two grids that often get confused. The layout grid is horizontal: columns and gutters that govern where blocks of content begin and end across the width. The baseline grid is vertical: an even rhythm that lines up text and spacing down the page. Designers tend to obsess over the first and ignore the second, which is backwards, because readers feel vertical rhythm more than they feel column alignment.
A grid earns its keep when removing it would make the page fall apart, not when adding it makes one screenshot look tidy.
The point of any grid is constraint. Instead of asking “where should this card go,” you ask “which columns does it span.” Instead of nudging margins by eye on every section, you reach for the same field width every time. A handful of rules generate a consistent surface across hundreds of components, and a new contributor can extend the layout without inventing values.
Choose the column count for the job
Twelve columns became the default for a good reason: twelve divides cleanly into halves, thirds, quarters, and sixths, so it supports the most common content splits without fractional widths. For most content sites and product UIs, start at twelve and stop second-guessing it.
That default is not a law. A dense data application or a marketing page with a lot of asymmetry can be better served by a finer grid. Some teams run a 16-column grid for exactly this reason. The trade-off is real: more columns buy more arrangement options, and they also make it easier to produce layouts nobody can reason about. If you cannot name why you need sixteen, you need twelve.
A few column counts and what they suit:
- Twelve columns. The general-purpose answer. Halves, thirds, and quarters all land on whole columns.
- Sixteen columns. Editorial layouts and dashboards that need finer asymmetry. More rope.
- Four to six columns. Phones and narrow panels, where twelve columns would each be too thin to mean anything.
Gutters, margins, and where the field stops
The gutter is the space between columns. Keep it consistent and tie it to your spacing scale rather than picking a stray number. A gutter that matches your base spacing unit makes the grid and the component padding agree, which is most of what “polish” actually is.
Margins are the breathing room at the outer edges. On large screens they protect line length and stop content from sprawling to the bezel. On phones they are often the only thing standing between your text and the edge of the glass, so they matter more there, not less.
The maximum width is the decision people skip, and it is the one that quietly ruins desktop layouts. Let a 12-column grid grow without a ceiling on a wide monitor and your paragraphs stretch past a comfortable reading measure, your hero text floats in a void, and nothing feels anchored. Cap the content field somewhere sensible, commonly in the range of 1200-1440px for the main column, and let the margins absorb the rest of the viewport. The grid grows; the content does not grow forever.
Breakpoints follow content, not device names
The fastest way to a brittle layout is to design three fixed comps for “mobile, tablet, desktop” and bolt them together. Devices do not cluster at those widths anymore, and the gaps between them are where layouts crack.
Design the smallest layout first, then widen the browser until the design looks strained, and put a breakpoint there. The content tells you where it wants to change: a card row that gets too cramped, a headline that wraps badly, a sidebar that finally has room to sit beside the main column instead of under it. This is the practical core of a mobile-first approach: start from the hardest constraint and add space as you get it, rather than cramming a desktop composition into a phone.
In practice your grid changes column count at breakpoints. A 12-column desktop grid might collapse to 6 columns on tablets and 4 on phones, with the gutters and margins adjusting to match. Components declare how many columns they span at each step, and the grid handles the rest.
CSS Grid, flexbox, and the framework grids of old
The implementation question used to be hard. It is not anymore. Native CSS Grid expresses real two-dimensional layout directly, which is what a page-level grid is. You define the tracks once and place items into them by line or by span, and the browser does the math that frameworks used to fake with floats and percentage widths.
A clean way to wire a 12-column field:
.layout {
display: grid;
grid-template-columns: repeat(12, 1fr);
gap: var(--gutter);
max-width: 1440px;
margin-inline: auto;
padding-inline: var(--margin);
}Reach for flexbox when the layout is one-dimensional: a row of items that should wrap, a toolbar, a list. Use CSS Grid when you are positioning content in two dimensions against shared column lines. The two are not rivals. Most real pages use Grid for the page skeleton and flexbox inside components. The old 12-column framework classes still work, but they solve a problem the platform now solves natively, with more markup and less control.
The baseline grid and vertical rhythm
Horizontal alignment gets the attention; vertical rhythm gets the feeling. A baseline grid sets a consistent vertical unit, and you size line heights and spacing as multiples of it so text and blocks line up down the page rather than drifting.
You do not need pixel-perfect baseline snapping to benefit. Pick a base unit, often 4px or 8px, and make every vertical measurement a multiple of it: line height, paragraph spacing, the gap above a heading, the padding inside a card. Suddenly two unrelated columns of text track together, and the page reads as composed. This is where layout and type meet, and it is why a grid and a type system should be designed as one decision, not two.
When to break the grid on purpose
A grid you never break produces pages that are correct and forgettable. The grid is a baseline of order so that your deliberate exceptions read as intent rather than accident. A full-bleed image that ignores the margins, a number that pushes past a column edge, an asymmetric hero: these land precisely because everything around them obeys the rules.
The discipline is to break it rarely and on purpose. One strong exception per view reads as confidence. Five reads as a layout with no grid at all. This is the same judgment that runs through solid UI design principles: structure first, then earn the moments that defy it.
How Strynal approaches grid systems
We do not start from a column count. We start from the content and the reading experience, then build the grid that serves them. The field width gets set against a comfortable measure for the longest body text. Breakpoints get placed where the content strains, not where a device chart says. The baseline unit is decided early so layout and typography share one rhythm from the first screen.
Because the team that scopes the work also builds it, the grid we hand to engineering is the grid that ships. There is no translation loss between a tidy design file and a layout that bends under real content, because the people who drew the columns are the ones writing the CSS Grid behind them.
If you are planning a site or product and want the layout to feel governed rather than guessed, our UI/UX design work is built around exactly this kind of structure. Tell us about the project on the contact page and we will start on a blank page, as we always do.