Most articles about spacing systems pick a side. 8px evangelists defend the 8-point grid. 4px advocates argue for more granularity. Custom-scale believers point at Stripe and Shopify. The truth is all three are right, for different contexts.
This is a cheat sheet, not a manifesto. It's the reference you save and return to when you're setting up a new design system or auditing an existing one. Decision framework at the top. Implementation recipes for Figma Variables, Tailwind, and CSS custom properties at the bottom. When to break the grid — and when not to — in the middle.
TL;DR — Quick Reference
- Default to 8px for most products. It's the industry standard (Material, Carbon) and it scales cleanly across devices.
- Use 4px as a sub-grid for tight internal spacing (button padding, icon + label, compact UI).
- Go custom only when you have a specific reason — dense data tables, fluid responsive layouts, or a brand visual language that requires it.
- Scale: 0, 4, 8, 12, 16, 24, 32, 48, 64, 96, 128. This covers 95% of spacing needs.
- Font sizes don't follow the spacing grid. Use a modular type scale instead.
- Internal ≤ external rule: space inside an element should be equal to or less than space around it. Keeps related elements grouped.
- Breaking the grid is fine when the alternative is worse — but document why, or the system rots.
The Decision Framework
Before setting up a spacing system, answer these three questions. Your answers determine whether you use 4px, 8px, or custom.
Question 1: What's your primary interface density?
Low density (marketing sites, content-focused products, consumer apps): go with 8px as the base unit. You don't need granular control; you need visual harmony.
Medium density (most SaaS products, dashboards with charts and data tables): 8px base, 4px sub-grid for tight spacing inside components (badge padding, icon-label gaps, compact button states).
High density (trading platforms, complex data tools, enterprise dashboards with deeply nested data): consider 4px as base. Every pixel matters when you're fitting six columns of data into a row.
Question 2: What's your target platform range?
Web-only, desktop-focused: 8px base is ideal. Desktop screens have room; the granularity of 4px isn't needed.
Mobile-first, responsive web: 8px still works (mobile screen widths of 360, 375, 390 all divide cleanly by 8). 4px sub-grid for tight mobile components.
Native mobile apps: 4px or 8px depending on iOS vs Android conventions. iOS HIG is less prescriptive; Material Design (Android) uses 8dp as base.
Multi-platform (web + iOS + Android): 8px base is the safest common denominator. Dp and pt values on mobile map cleanly.
Question 3: How much custom do you really need?
Most teams don't need a custom system. The 8px scale (or 4px sub-grid) covers 95% of use cases. Custom systems make sense when:
- Your brand has a defining visual rhythm that requires unusual proportions (golden ratio, modular scale ratios).
- You've built for dense data and need tighter spacing than 4px even (rare).
- You're building a design system for an industry with unusual constraints (e-readers, TVs, in-car displays).
If none of those apply to you, use 8px. The cost of custom is carrying the complexity forever; the benefit is usually marginal.
The Standard Scale (Use This Unless You Have a Reason Not To)
The default scale that covers almost every product:
| Token | Value | Common Use |
|-------|-------|------------|
| 0 | 0px | Zero, reset |
| xs | 4px | Icon + text gap, tight badge padding |
| sm | 8px | Button internal padding, form field gaps |
| md | 12px | Card internal spacing |
| base | 16px | Paragraph margin, section spacing |
| lg | 24px | Card margin, section padding |
| xl | 32px | Major layout spacing |
| 2xl | 48px | Section breaks on desktop |
| 3xl | 64px | Large hero padding, page sections |
| 4xl | 96px | Page-level spacing |
| 5xl | 128px | Marketing site hero breaks |
T-shirt sizing (xs, sm, md, lg, xl) is more maintainable than numeric naming (space-4, space-8). When you need to add a value between two existing ones, numeric names break; T-shirt names stay stable.
The Rules That Matter
Three rules that prevent the most common spacing mistakes.
Rule 1: Internal ≤ External
The space inside a grouped element should be equal to or less than the space around it. A card with 16px internal padding should have at least 16px of space around it. If the internal and external spaces are equal, elements feel balanced. If internal exceeds external, elements feel crowded.
This rule comes from Gestalt psychology — specifically the law of proximity. Elements that are closer together are perceived as related; elements that are farther apart are perceived as separate. Break this rule and your UI starts to feel either crowded (internal > external) or empty (external way > internal).
Rule 2: Font sizes don't follow the spacing grid
This is the most common mistake. Designers set up an 8px spacing grid and then try to force font sizes onto it — 16px, 24px, 32px. The result is a limited, sometimes awkward type scale.
Font sizes should follow a modular scale. Common choices: 1.2 (minor third), 1.25 (major third), 1.333 (perfect fourth). With a 16px base and a 1.25 ratio, you get sizes like 12.8, 16, 20, 25, 31.25, 39, 48.8. Round to the nearest whole pixel for practical use.
What should follow the grid is line-height, not font-size. A 14px font with a 20px line height keeps baselines aligned to the grid even when the font itself doesn't.
Rule 3: The escape hatch is fine, but document it
Sometimes 8px is too much and 4px is too little. A border-radius of 6px. A negative margin of 2px. A label that needs 10px of space to avoid overlapping an icon. In real products, these exceptions exist and fighting them is worse than allowing them.
The rule: exceptions are fine, but they should be named and documented. "chip-padding: 6px" in your tokens is better than an anonymous hack. Once named, it becomes part of the system — either to use broadly or to remove when something better is designed.
Implementation: Figma Variables
Setting up spacing as Figma Variables is the foundation of modern design system work. Here's the minimal setup.
Step 1: Create a collection
In Figma, open Local Variables → Create Collection → Name it "Spacing" (or similar). Keep spacing separate from color, typography, and radius collections.
Step 2: Create the base scale
Add these variables as numeric values:
space/0= 0space/xs= 4space/sm= 8space/md= 12space/base= 16space/lg= 24space/xl= 32space/2xl= 48space/3xl= 64space/4xl= 96
The slashes create nesting in the Figma variables panel — helpful as the system grows.
Step 3: Apply in Auto Layout
In any frame with Auto Layout, click the gap, horizontal padding, or vertical padding control. An icon appears on hover to bind to a variable. Apply the relevant token. Do this across your components.
Step 4: Document exceptions
When a component needs a value outside the standard scale, add it to the collection with a descriptive name (space/chip-padding-y, space/field-inner-gap). Don't just hardcode numbers in components — that's how drift starts.
Implementation: Tailwind CSS
Tailwind's default spacing scale is already close to the industry standard. Here's how to align it with your design tokens.
Tailwind v4 note (January 2025 release): Tailwind v4 shifted configuration from tailwind.config.js to CSS-first config using @theme directives and CSS custom properties. Spacing tokens are now defined directly in CSS with --spacing-* variables, which maps more cleanly to the W3C Design Tokens Community Group DTCG 2025.10 format. If you're setting up a new project in 2026, start with v4; existing v3 projects can migrate at their own pace.
Default Tailwind scale (v3 and v4 compatible)
Tailwind's default spacing uses a 4-based scale (0, 0.5, 1, 1.5, 2, 2.5, 3...) mapped to 0, 2, 4, 6, 8, 10, 12px. This is fine for most projects — it gives you 4px sub-grid by default.
Minimal customization
Tailwind's default spacing uses a 4-based scale (0, 0.5, 1, 1.5, 2, 2.5, 3...) mapped to 0, 2, 4, 6, 8, 10, 12px. This is fine for most projects — it gives you 4px sub-grid by default.
Custom scale to match design tokens
In tailwind.config.js:
Now p-base, gap-sm, mt-lg all map to your design tokens. Your Tailwind classes become your design system.
Extending rather than replacing
If you want to keep Tailwind's defaults and add your named tokens on top:
Implementation: CSS Custom Properties
If you're not using Tailwind, raw CSS custom properties work equivalently:
The advantage of CSS custom properties over SCSS variables is runtime access — you can change them dynamically (useful for user-configurable density, for example). This is how most production design systems handle spacing tokens in 2026.
Keeping Figma and Code in Sync
The discipline that matters most is single-source tokens. When Figma variables and CSS custom properties are maintained separately, they drift. Within months, your 16px in Figma will be 15.5px in code and nobody will remember why.
The standard solutions:
Style Dictionary (open-source, Amazon-maintained): define tokens in JSON, generate Figma variables, CSS, Tailwind config, iOS, and Android from a single source. Most rigorous option.
Tokens Studio for Figma: manage tokens in Figma, export as JSON, sync to your codebase via GitHub Actions. Most designer-friendly option.
Custom token pipelines: homegrown scripts that read from one source and update the other. Most common in practice; most fragile long-term.
Pick one and commit. The cost of drift is higher than the cost of the tooling setup.
Custom Spacing Systems Worth Knowing About
If you decide you need a custom system — and you've read the "you probably don't" section above and still decided yes — here are three custom approaches that work.
Golden ratio spacing: 1, 1.618, 2.618, 4.236... Applied to a base unit (usually 8px), this produces 8, 13, 21, 34, 55. Used in visual design work where brand proportions matter. Rare in product design because the non-whole numbers don't map cleanly to screen pixels.
Modular scale (non-8): any ratio applied to a base. 1.2 ratio with 8 base = 8, 9.6, 11.5, 13.8, 16.6, 19.9... Gives you a custom set of whole-ish numbers. Works for brand-driven work where you want unique proportions.
Stripe's hybrid system: Stripe uses 4px base with specific named exceptions for common UI patterns (the "ribbon" at the top of their dashboard has specific padding that doesn't match the generic grid). Custom where needed, consistent where possible.
Shopify Polaris: uses 4px base with a named scale (space-050, space-100, space-200, etc.) that maps to pixel values. The naming abstracts the underlying values, which means they can evolve without renaming.
When to Break the Grid
The grid is a tool, not a religion. Break it when:
- Centering an element requires a half-pixel offset (2px instead of 4 or 8).
- An icon's optical center requires a nudge to align with adjacent text.
- A border affects visual weight and needs a small compensating margin.
- A tight component (a badge, a tag) reads better at 6px padding than 8px.
Don't break it when:
- You just prefer a different number. Preference isn't a reason; it's drift.
- A stakeholder said it should be bigger or smaller without a specific reason.
- You're matching an inspiration image exactly, including its accidental spacing.
The question to ask before breaking the grid: is there a principle or observation I can document, or is this a one-off gut reaction? If it's the former, update the system. If it's the latter, don't break the grid — adjust your gut reaction.
Frequently Asked Questions
Should I use 4px or 8px grid?
Use 8px as your base for most products, with 4px as a sub-grid for tight internal spacing inside components (button padding, icon-label gaps). Pure 4px base systems make sense for high-density interfaces like trading platforms or complex data tools where every pixel matters. For the large majority of SaaS, consumer apps, and marketing sites, 8px base with a 4px sub-grid is the right default.
What is the 8 point grid system?
The 8-point grid is a spacing system where all dimensions — padding, margin, line height, component sizes — are multiples of 8 pixels. Common values are 8, 16, 24, 32, 48, 64. The benefits are scalability (multiples of 8 map cleanly to common screen sizes and pixel densities), visual rhythm (repeating proportional values feel orderly), and simplified decision-making (a short scale to choose from instead of arbitrary numbers). Most major design systems, including Material Design and Carbon, use it as their base.
Why do designers use 8px spacing?
Three main reasons. First, most common screen dimensions divide cleanly by 8 (360, 375, 390, 768, 1024, 1440), so elements align with pixel grids across devices. Second, 8 has good integer factors (1, 2, 4, 8), which means you can scale down to 4 or 2 for tighter spaces or up to 16, 32, 64 for larger layouts without hitting awkward in-between values. Third, it's the established industry standard — using 8px means designers moving between products don't have to relearn the system.
What is the internal less than external rule?
It's a spacing principle from Gestalt psychology: the space inside a grouped element should be equal to or less than the space around it. A card with 16px internal padding should have at least 16px of margin around it. When internal spacing exceeds external spacing, elements feel visually crowded — the grouping signals get mixed. When external spacing is much greater than internal, elements feel sparse. Following this rule keeps related items grouped and unrelated items separated.
What spacing should I use in Figma?
Set up Figma Variables for your spacing scale: 0, 4, 8, 12, 16, 24, 32, 48, 64 with T-shirt naming (xs, sm, md, base, lg, xl, 2xl, 3xl). Apply them in Auto Layout for gap, horizontal padding, and vertical padding. Never hard-code pixel values in components — bind to variables. This keeps spacing consistent across your Figma file and allows global updates. For implementation in code, either pair with Tailwind (customize theme.spacing) or export as CSS custom properties via Tokens Studio or Style Dictionary.
How do I set up spacing tokens?
Start with a JSON file as the single source: { "space": { "xs": "4px", "sm": "8px", "base": "16px", ... } }. Use a tool like Style Dictionary to generate Figma variables, CSS custom properties, Tailwind config, and mobile platform code from that one file. If you're smaller-scale, Tokens Studio for Figma offers a lighter setup — manage tokens inside Figma and sync to code via GitHub. The critical discipline is never maintaining two sources of truth — that's how drift starts.
For related design system practices, read [Why Most Design Systems Get Abandoned in 2026](https://mantlr.com/blog/why-design-systems-abandoned) and [The Figma File Structure Senior Designers Actually Use](https://mantlr.com/blog/figma-file-structure-senior-designers). For the color token equivalent to this spacing guide, see [The Color Systems Guide: How Stripe, Linear, and Radix Scale Color in 2026](https://mantlr.com/blog/color-systems-that-scale). For the design handoff workflow that design tokens anchor, see [Design Handoff in 2026](https://mantlr.com/blog/design-handoff-2026-dev-mode-mcp).
For the tooling side, browse Mantlr's curated [Figma resources](https://mantlr.com/categories/figma-resources), [design system tools](https://mantlr.com/categories/design-systems), and [Tailwind resources](https://mantlr.com/categories/tailwind).
Primary source references (all retrieved April 24, 2026):