Safe Starting Points
Sensible values to begin from when no standard gives a hard answer. None of these is a rule, and none changes purely because of the device: each row says what it depends on.
Viewport: All
Viewport references are useful starting points. Design breakpoints should respond to the content, not specific device models. Choosing a viewport changes what is emphasised; nothing is hidden.
Base spacing unit
Industry conventionSafe starting point
4 / 8 px base
Product UI on any platform.
Applies to All viewports
Why, and when to change it
A short scale turns hundreds of small spacing decisions into a handful, and makes spacing differences large enough to read as intentional.
Common range. 4, 8, 12, 16, 24, 32, 40, 48, 64
When to deviate. Follow your design system's scale if you have one. Dense tools often add 2 and 6; editorial pages often need steps above 64.
Official guidance
- SGDS
A 4-point system, with sizes 4, 8, 12, 16, 20, 24, 32, 48, 64, 96 and 128 px.
SGDS, Spacing(opens in a new tab)Design-system convention
- GOV.UK
A 5 px based scale: 5, 10, 15, 20, 25, 30, 40, 50, 60. Larger steps shrink on small screens.
GOV.UK Design System, Spacing(opens in a new tab)Design-system convention
Card padding
Industry conventionSafe starting point
16–24 px
Standard desktop product card.
- Mobile
- 12–16 px
- Tablet
- 16–20 px
- Laptop
- 16–24 px
- Desktop
- 16–24 px
- Large desktop
- 20–32 px
Depends on information density, component size, touch interaction, product type, your design system. A starting point, not a correct value.
Why, and when to change it
This range tends to give a desktop product card room to breathe while keeping useful density. Compact enterprise tools go lower; large editorial cards go higher.
Common range. 8–12 compact control, 16–24 standard card, 24–32 large content card
When to deviate. Go tighter when people scan many items at once. Go looser when a card holds one thing people read carefully.
Section spacing
Industry conventionSafe starting point
40–64 px
Between major page sections, desktop.
- Mobile
- 24–40 px
- Tablet
- 32–48 px
- Laptop
- 40–64 pxSame as desktop
- Desktop
- 40–64 px
- Large desktop
- 48–80 px
Depends on how much each section holds, density, whether the page is read or worked in. A starting point, not a correct value.
Why, and when to change it
Sections need a gap clearly larger than anything inside them, or the page reads as one undivided list.
Common range. 32–48 in product UI, 48–96 on content pages
When to deviate. Tighten in dense tools where people work in one screenful. Loosen on long reading pages.
Body text
Industry conventionSafe starting point
14–16 px
Product UI.
- Mobile
- 14–16 px
- Tablet
- 14–16 px
- Laptop
- 14–16 pxSame as desktop
- Desktop
- 14–16 px
- Large desktop
- 14–18 px
Depends on reading or scanning, viewing distance, density. A starting point, not a correct value.
Why, and when to change it
16 px is the browser default and comfortable for sustained reading. Product UI often drops to 14 to fit more on screen.
Common range. 14 in dense product UI, 16 for reading, 12–14 for supporting text
When to deviate. Use 16 or more for anything people read at length, and on mobile. Keep 12 for captions and metadata only.
Official guidance
- SGDS
Body text is 16 px.
SGDS, Typography(opens in a new tab)Design-system convention
- GOV.UK
Body text is 19 px with a 25 px line height.
GOV.UK Design System, Type scale(opens in a new tab)Design-system convention
- WCAG
Text must be resizable to 200 percent without loss of content or function.
WCAG 2.2, SC 1.4.4 Resize Text(opens in a new tab)Standard requirement
Body line height
Industry conventionSafe starting point
1.4–1.6
Paragraph text.
Applies to All viewports
Why, and when to change it
Body text needs room for the eye to find the next line. Large headings need less, or their lines drift apart.
Common range. 1.4–1.6 for body, 1.1–1.3 for headings
When to deviate. Tighten for short UI labels and large display text. Loosen for long lines or small text.
Official guidance
- SGDS
1.5 for body, labels and captions; 1.2 for displays, headings and subtitles.
SGDS, Typography(opens in a new tab)Design-system convention
- WCAG
Nothing may break when users set line height to at least 1.5 times the font size.
WCAG 2.2, SC 1.4.12 Text Spacing(opens in a new tab)Standard requirement
Reading line length
Industry conventionSafe starting point
45–75 characters
Paragraphs.
Applies to All viewports
Why, and when to change it
Long lines make it hard to find the start of the next line; very short lines break phrases apart.
Common range. 45–75 for body text, shorter for captions
When to deviate. Tables, code and UI labels are not reading text and do not need the limit.
Official guidance
- SGDS
Keep long body text to 40 to 60 characters per line, and short text to 20 to 40.
SGDS, Typography(opens in a new tab)Design-system convention
General radius
Industry conventionSafe starting point
6–8 px
Buttons, fields and cards in product UI.
Applies to All viewports
Why, and when to change it
Radius sets the tone of a product more than almost any other value, and inconsistency in it is easy to see.
Common range. 0–4 sharp, 6–8 general, 10–12 softer, 16–24 large surfaces, full for pills
When to deviate. Follow the platform or design system first. Scale radius with size: a large radius on a small control turns it into a pill.
Official guidance
- SGDS
0 and 2 px for tables and dividers; 4 px for tags and small icon buttons; 8 px for cards, modals, dropdowns and inputs; 12 and 16 px for large modals and banners; 24 px for feature cards; full for avatars.
SGDS, Border(opens in a new tab)Design-system convention
- Material
Shape scale: extra small 4 dp, small 8 dp, medium 12 dp, large 16 dp, extra large 24 dp.
Android Developers, Material Design 3 in Compose(opens in a new tab)Design-system convention
Content width
Industry conventionSafe starting point
1200–1440 px
Application layouts, desktop.
- Mobile
- Full width, inside the page margins
- Tablet
- Full width, inside the page margins
- Laptop
- Full width up to the maximum
- Desktop
- 1200–1440 px maximum
- Large desktop
- Hold the maximum; let the margins grow
Depends on what the content is, whether people read or scan it. A starting point, not a correct value.
Why, and when to change it
Past a point, extra width only stretches lines and spreads related things apart.
Common range. 1200–1440 for application layouts, 600–760 for reading columns
When to deviate. Data tables and canvases can use the full width. Forms and articles should be much narrower.
Official guidance
- GOV.UK
Default maximum page width is 1020 px; prefer a two-thirds column for readability.
GOV.UK Design System, Layout, and GOV.UK Frontend Sass API ($govuk-breakpoints)(opens in a new tab)Design-system convention
- SGDS
Deliver at least 320, 768 and 1440 px layouts.
SGDS, Layout, Breakpoint(opens in a new tab)Design-system convention
- Atlassian
A fixed-wide grid has a maximum width of 1296 px. A fixed-narrow grid, for long-form reading, has a maximum of 864 px.
Atlassian Design System, Grid(opens in a new tab)Design-system convention
Input height
Industry conventionSafe starting point
40–48 px
Desktop forms.
- Mobile
- 44–48 px
- Tablet
- 44–48 px
- Laptop
- 40–48 pxSame as desktop
- Desktop
- 40–48 px
- Large desktop
- 40–48 pxSame as desktop
Depends on touch or pointer, density, how many fields share the screen. A starting point, not a correct value.
Why, and when to change it
Shared height lets controls sit on one baseline, and 40 px or more is comfortable to click and tap.
Common range. 32–36 compact, 40–48 standard
When to deviate. Filters and table toolbars can be shorter. Dense enterprise screens may use smaller controls, but check they are still easy to hit and read. Do not use one density everywhere by default.
Page margins
Industry conventionSafe starting point
32–64 px
Desktop. 16–20 px on mobile.
- Mobile
- 16–20 px
- Tablet
- 24–32 px
- Laptop
- 32–64 pxSame as desktop
- Desktop
- 32–64 px
- Large desktop
- 48–80 px
Depends on container strategy, whether content has a maximum width, density. A starting point, not a correct value.
Why, and when to change it
Content needs to clear the screen edge, and on a phone every pixel of margin is taken from the content. So margins start small and grow with the space available.
When to deviate. Full-bleed media, maps and data canvases can run to the edge. Keep text and controls inside the margin.
Official guidance
- SGDS
Deliver at least 320, 768 and 1440 px layouts.
SGDS, Layout, Breakpoint(opens in a new tab)Design-system convention
- GOV.UK
The responsive spacing scale uses smaller values on small screens for its larger steps.
GOV.UK Design System, Spacing(opens in a new tab)Design-system convention
- Atlassian
Grid margins are 16 px for viewports up to 1023 px and 32 px from 1024 px.
Atlassian Design System, Grid(opens in a new tab)Design-system convention
Gaps
Industry conventionSafe starting point
Small 4–12, medium 12–24, large 24–40 px
Between elements, desktop.
- Mobile
- Small 4–8, medium 8–16, large 16–24 px
- Tablet
- No separate value. Use the nearest one.
- Laptop
- Small 4–12, medium 12–24, large 24–40 pxSame as desktop
- Desktop
- Small 4–12, medium 12–24, large 24–40 px
- Large desktop
- Small 4–12, medium 12–24, large 24–40 pxSame as desktop
Depends on how closely the elements relate, density, touch interaction. A starting point, not a correct value.
Why, and when to change it
People read distance as relatedness. Three clearly different gaps are enough to show what belongs together, on any screen.
When to deviate. On mobile the large gap shrinks most, because vertical space is scarce. Keep the gap between tappable items large enough that a finger does not hit the neighbour.
Columns
Industry conventionSafe starting point
2–4 columns
Content grids, desktop.
- Mobile
- 1 column
- Tablet
- 1–2 columns
- Laptop
- 2–3 columns
- Desktop
- 2–4 columns
- Large desktop
- Hold the count; cap the width
Depends on what each column holds, minimum useful width of one item, whether items are compared or read. A starting point, not a correct value.
Why, and when to change it
A column is useful while each item in it stays wide enough to read. Past that, extra columns make every item worse.
When to deviate. Dense grids of small, uniform items, such as thumbnails, can go well past four. Long text should stay in one column at any width.
Official guidance
- Atlassian
The grid has 2 columns from 320 px, 6 from 480 px and 12 from 1024 px.
Atlassian Design System, Grid(opens in a new tab)Design-system convention
- Apple
On iPhone Duo a split view expands on the inner display and collapses to a single pane on the outer display. In a grid, prefer an even number of columns so content divides cleanly at the fold.
Apple HIG, Designing for iPhone Duo(opens in a new tab)Design-system convention
Applies to foldable
- Material
A large unfolded foldable in landscape is like a tablet, and a two-pane layout makes good use of the width. Folded, a single column is straightforward and effective.
Android Developers, Learn about foldables(opens in a new tab)Design-system convention
Applies to foldable
Table behaviour
Industry convention- Mobile
- Stacked rows, key and value pairs, card-like row details or expandable rows
- Tablet
- Fewer columns, chosen by priority; sideways scrolling only when needed
- Laptop
- The full table: sticky header, resizable columns, bulk actionsSame as desktop
- Desktop
- The full table: sticky header, resizable columns, bulk actions
- Large desktop
- The full table: sticky header, resizable columns, bulk actionsSame as desktop
Depends on whether people compare across rows, how many columns matter, touch or pointer. A starting point, not a correct value.
Why, and when to change it
On a wide screen people compare down columns. On a phone there is room for about two columns, so comparison has to give way to reading one row at a time.
Official guidance
- WCAG
Content must work at 320 CSS pixels without scrolling in two directions. Data tables that need two dimensions are exempt.
WCAG 2.2, SC 1.4.10 Reflow(opens in a new tab)Standard requirement
Applies to all viewports
Modal width
Industry conventionSafe starting point
560–720 px
Medium modal, desktop.
- Mobile
- Full width or full screen
- Tablet
- Sized to content, inside the page margins
- Laptop
- Small 400–480, medium 560–720, large 800–960 pxSame as desktop
- Desktop
- Small 400–480, medium 560–720, large 800–960 px
- Large desktop
- Small 400–480, medium 560–720, large 800–960 pxSame as desktop
Depends on how much the modal holds, whether it contains a form, touch or pointer. A starting point, not a correct value.
Why, and when to change it
A modal should be as wide as its content needs and no wider. On a phone there is no room for a margin around it that does any good.
When to deviate. If a modal needs the large size on desktop, or scrolls on mobile, it is often a page or a full-screen step instead.
Official guidance
- SGDS
Five sizes: small, medium (default), large, extra large and fullscreen.
SGDS, Modal(opens in a new tab)Design-system convention
- Carbon
Four responsive sizes: extra small, small, medium and large.
Carbon, Modal usage(opens in a new tab)Design-system convention
- USWDS
Two sizes: default and large.
USWDS, Modal(opens in a new tab)Design-system convention
- Atlassian
The usage page gives no pixel widths.
Atlassian Design System, Modal dialog usage(opens in a new tab)Design-system convention
Drawer width
Industry conventionSafe starting point
320–480 px
Side panel, desktop.
- Mobile
- Full width or nearly, often from the bottom
- Tablet
- A moderate width, about half the viewport
- Laptop
- 320–480 px side panelSame as desktop
- Desktop
- 320–480 px side panel
- Large desktop
- 320–480 px side panelSame as desktop
Depends on what the drawer holds, whether the page behind stays usable, touch or pointer. A starting point, not a correct value.
Why, and when to change it
A drawer earns its place by leaving the page visible. On a phone there is no page left to show beside it, so it takes the width and the page waits behind.
When to deviate. A drawer holding a table or a preview can be wider on desktop. Past about half the viewport it stops reading as a drawer.
Loading feedback
Industry conventionSafe starting point
None under 1 s
Chosen by how long the wait is.
Applies to All viewports
Why, and when to change it
Feedback that appears and vanishes inside a moment reads as a flicker. Feedback that never changes during a long wait reads as a crash.
Common range. No indicator under about 1 s, an indicator from 1 to 10 s, progress beyond 10 s
When to deviate. On slow or unreliable connections, show the layout straight away and fill it in, even for short waits. People on those connections expect to wait and need to know it is working.
Official guidance
- NN/g
0.1 second is about the limit for feeling instantaneous. 1 second is about the limit for an uninterrupted flow of thought. 10 seconds is about the limit for keeping attention on the task.
NN/g, Response Times: The 3 Important Limits(opens in a new tab)Research-based best practice
- NN/g
As a rule of thumb, use percent-done progress indicators for operations taking more than about 10 seconds.
NN/g, Response Times: The 3 Important Limits(opens in a new tab)Research-based best practice
- WCAG
Status messages must be available to assistive technology without receiving focus.
WCAG 2.2, SC 4.1.3 Status Messages(opens in a new tab)Standard requirement
Applies to all viewports
Icon size
Industry conventionSafe starting point
16–24 px
Inside controls, desktop.
- Mobile
- 20–24 px
- Tablet
- 20–24 px
- Laptop
- 16–20 pxSame as desktop
- Desktop
- 16–20 px
- Large desktop
- 16–20 pxSame as desktop
Depends on touch or pointer, the text size beside it, density. A starting point, not a correct value.
Why, and when to change it
An icon should sit comfortably beside its label, so it follows the text size. The target around it follows the input method.
Common range. 16 inline with text, 20 in controls, 24 in navigation and on touch
Official guidance
- WCAG
Graphics needed to understand content, and the visual parts of controls, need at least 3:1 contrast against adjacent colours.
WCAG 2.2, SC 1.4.11 Non-text Contrast(opens in a new tab)Standard requirement
Applies to all viewports
- WCAG
The pointer target must be at least 24 by 24 CSS pixels.
WCAG 2.2, SC 2.5.8 Target Size (Minimum)(opens in a new tab)Standard requirement
Applies to all viewports · touch and pointer input
- Fluent
Button icons must pass 3:1 contrast against their background in all interactive states.
Fluent 2, Button usage(opens in a new tab)Design-system convention