Spacing is the quietest part of any interface. Designers obsess over colour, type, and layout, yet inconsistent spacing is often what makes a finished product feel rough rather than refined. A spacing system built on the 8pt grid solves this before it becomes a problem.
Why Spacing Breaks Down Without a System
Spacing accumulates by accident. One component uses 12px padding, the next uses 15px because it looked right. A modal gets 20px inside, a card gets 24px, a sidebar uses 16px. Nothing is technically wrong, but the sum feels off. Users can’t name it; they just sense disorder.
The root cause is usually the same: developers and designers making independent decisions from a blank value-space with no shared reference. A spacing system closes that gap by defining a finite set of valid values before any component is built. This is the same reason consistent spacing rhythm sits inside the principles that never go out of style: users may not consciously notice it, but they feel it.
The Case for 8pt as the Base Unit
Why 8? The number is not arbitrary. Most modern displays use pixel densities that are multiples of 8 (1x, 2x, 3x). An 8pt value renders without sub-pixel rounding across all of them. 4pt works for the same reason and serves as a useful half-step, but 8pt gives you the bigger building blocks that most layout decisions require.
There is also a mathematical convenience. 8 divides evenly into 2, 4, and 8. Scale values multiply cleanly: 8, 16, 24, 32, 48, 64, 96. No awkward remainders, no temptation to introduce 13px because 16px felt too generous for a particular element.
An 8pt grid is not a constraint. It is a pre-made decision that frees you to spend creative energy on the parts of the design that actually need it.
Compare this to an arbitrary spacing approach, where each decision is made fresh. Over a codebase of 50 components, you will accumulate dozens of unique pixel values. Consolidating them later is tedious audit work. Designing to the grid from the start skips that entirely.
Building Your Scale
Start with 8 as the base unit and work outward. A practical scale for most interfaces looks like this:
- 4 (half-step: icon nudges, tight inline gaps between adjacent labels)
- 8 (base: small internal padding, space between a label and its value)
- 12 (optional intermediate: useful inside compact components like chips or badges)
- 16 (comfortable padding for most form elements and cards)
- 24 (section-internal rhythm: space below headings, between list items)
- 32 (layout separators within a content section)
- 48 (breathing room between distinct content blocks)
- 64 and 96 (major section breaks, hero-to-content transitions on marketing pages)
You don’t use every step everywhere. The 4 and 12 values are micro-steps for situations where 8 is too much and 0 is too little. Values of 64 and above appear mainly at the page structure level, not inside components.
This scale pairs well with a grid system: columns handle horizontal structure, and the spacing scale handles the vertical rhythm between rows, sections, and components.
Naming the Tokens
Avoid naming tokens by their pixel value. spacing-16 tells you nothing about intent, and if you ever adjust the scale, all your names become misleading.
Two patterns work well in practice.
T-shirt sizing: xs, sm, md, lg, xl, 2xl, 3xl. Readable in Figma and in code, and easy to extend. The risk is that “medium” can mean different things to different people, so document the intended use of each step explicitly.
Semantic naming: tight, base, comfortable, loose, section, page. More explicit about use but harder to extend when you discover you need something between comfortable and loose.
Either pattern beats numeric names. The choice matters less than applying it consistently: Figma variables, CSS custom properties, and any design-token file should all share the same names. This kind of coordinated naming is closely related to the approach behind a semantic colour system, where the token name carries meaning rather than a raw value.
In CSS, the mapping is straightforward:
:root {
--spacing-xs: 0.25rem; /* 4px */
--spacing-sm: 0.5rem; /* 8px */
--spacing-md: 1rem; /* 16px */
--spacing-lg: 1.5rem; /* 24px */
--spacing-xl: 2rem; /* 32px */
--spacing-2xl: 3rem; /* 48px */
--spacing-3xl: 4rem; /* 64px */
}Using rem rather than px means the scale respects user browser zoom preferences. A web typography system benefits from the same logic: type and spacing scale together when both are expressed in rem.
Applying the Scale to Real Layouts
Internal component spacing (padding inside buttons, cards, and form fields) typically lives at sm to md. The gap between a label and its input, or between an icon and its text, usually calls for xs.
Space between components within the same page section (adjacent cards, a grouped list) sits in the md to lg range. Separating distinct content blocks pushes into xl and 2xl. Major page sections, particularly on marketing pages, often use 3xl or a custom large value defined in the same token file.
The principle is the same one that governs visual hierarchy: the larger the conceptual distance between two pieces of content, the more space between them. A heading and its sub-heading are closely related, so they sit close together. A new section with a different subject gets generous breathing room. Readers should not have to think about why the page feels the way it does; the spacing communicates the structure silently.
When to Break the Rules
The 8pt grid is a guide, not a law. There are legitimate exceptions.
Borders and dividers at 1px don’t need to conform to the grid. Optical nudges of 1–2px to align an icon visually with its text are fine. In dense data tables, 6px row padding may genuinely read better than 8px.
The trap is breaking the grid out of impatience. When a designer uses 10px because they couldn’t decide between 8 and 12, that value should be revisited. When they use 1px because a 1px divider is what the design calls for, that’s correct. The distinction is intent. Every exception should have a named reason. Any value that exists because it “felt right” is a candidate for the next round of cleanup.
How Strynal Approaches Spacing Systems
Spacing systems are one of the foundational decisions on every project at Strynal. We define the scale before the first component is designed and token it before the first line of code is written. That means everyone working on layout, whether in Figma or in CSS, draws from the same set of values.
Our UI/UX work includes this kind of system thinking from the start. A spacing system alone does not guarantee a good interface, but a missing one guarantees a fragmented one. The audit work required to reconcile inconsistent spacing across a live codebase consistently costs more than building the system would have at the outset.
If you are starting a new product or rebuilding an existing one, get in touch. We will help you build the spacing foundation right from the beginning.