Skip to content
UX Atlas
Plate FND·045 · UI foundationGrid D1 · Rev. 2026-08-14

Breakpoints

The widths at which the layout changes, chosen from where the content breaks rather than from a device list.

UI foundationCraft conventionFoundational

Definition

A breakpoint is a viewport or container width at which layout rules change. The durable approach is to add a breakpoint where the content stops working, not where a popular device happens to be.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2A conventional set
  3. 3Practice
  4. 4Choosing where to break
  5. 5In practice
  6. 6Local chart
  7. 7Continue from here

Reach for this when

  • Setting up a responsive system.
  • Deciding where a layout should change structure.

Common mistakes

  • Breakpoints derived from a device list.
  • Too many breakpoints.
  • Pixel-based media queries that ignore user font size.
  • Naming breakpoints after devices, which quietly encourages designing for those devices rather than for the content.

A conventional set

These are widely used defaults, useful as a shared vocabulary. Add or remove breakpoints based on where your content actually breaks.

NameMin widthTypical shift
sm640pxSmall elements move onto one line.
md768pxTwo-column layouts become viable.
lg1024pxPersistent navigation appears; three panes become possible.
xl1280pxWider content and larger media.
2xl1536pxMaximum container width reached; extra space becomes margin.

Practice

  • Work mobile first, using min-width queries. Base styles are the small layout and each breakpoint adds.
  • Test between breakpoints, not at them. Failures occur in the ranges, not at the boundaries.
  • Use em or rem in media queries so they respond to the user's font size setting.
  • Prefer container queries for components, and keep media queries for page-level structure.
  • Fewer breakpoints is better. Each one multiplies testing and review effort.

Choosing where to break

Do

  • Add a breakpoint where the content stops working, and only there.
  • Use the same handful across the product, and write them down.
  • Prefer intrinsic layout first, which removes most of the need for them.
  • Test between breakpoints, where the layout has the least attention.

Do not

  • Copy a device-width list and treat it as a specification.
  • Add a breakpoint per component, which makes the product behave differently region by region.
  • Design three fixed widths and treat everything else as an accident.

In practice

  1. i.

    Content-driven breakpoints

    Responsive design

    A navigation bar that fits until 880px should break at 880px, not at 768px because that is the conventional tablet value. The content defines the boundary.

  2. ii.

    Content-driven, not device-driven

    Where the break belongs

    A card row broke when the third card fell under about 280 pixels wide, which happened at 940 pixels of viewport. That is where the breakpoint belongs, and it corresponds to no device in any list.

Local chart

FND·045 · Region II · Grid D1

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

BreakpointTERM·044 · SHORT DEFINITIONResponsive DesignTERM·043 · SHORT DEFINITIONViewportTERM·045 · SHORT DEFINITIONReflow and ZoomA11Y·013 · RELATED CONCEPTAdaptive LayoutFND·044 · RELATED CONCEPTCompositionFND·014 · RELATED CONCEPTContainersFND·041 · RELATED CONCEPTGridsFND·039 · RELATED CONCEPTResponsive LayoutFND·043 · RELATED CONCEPTResponsive TypographyFND·038 · RELATED CONCEPT

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Short definition

The one-paragraph version, for when that is all you need.

Related concept

Connected closely enough to change how you apply this.