Sass Breakpoints

What Makes a Good Breakpoint Scale?

A good breakpoint scale reflects genuine layout shifts in your design, not arbitrary device widths. Most projects need somewhere between four and six breakpoints; more than that usually indicates the design itself needs simplifying rather than adding more responsive complexity.

$breakpoints: (
  sm: 576px,
  md: 768px,
  lg: 992px,
  xl: 1200px,
  xxl: 1400px,
);

This is one of the most widely used breakpoint scales, closely matching Bootstrap's default breakpoints, and works well as a starting point for most projects.

Common Breakpoint Values

sm: 576px   // small tablets / large phones
md: 768px   // tablets
lg: 992px   // small desktops / landscape tablets
xl: 1200px  // desktops
xxl: 1400px // large desktops

• These values are widely recognized conventions, not rigid rules, adjust them to your actual designs.
• Name breakpoints semantically (sm, md, lg) rather than by specific device names, which change over time.
• Only add a breakpoint when a real layout shift is needed at that width, not preemptively.
• Keep the breakpoint map in exactly one place and reference it everywhere else.

Breakpoints Cheatsheet

A widely used breakpoint scale and what each tier typically targets.

Designing From Content, Not Devices

Modern responsive design practice recommends choosing breakpoints based on where your actual content or layout starts to look cramped or awkward, rather than targeting specific device widths, since device sizes vary constantly and the content-based approach ages better.

How Many Breakpoints Do You Actually Need?

Every additional breakpoint multiplies the number of states a component can be in, and the number of combinations a developer needs to test. Most projects are well served by four to six breakpoints; needing many more is often a sign the design itself has grown too complex.

• Start with the minimum number of breakpoints that solve real layout problems in your designs.
• Add a new breakpoint only when a specific, observed layout issue justifies it.
• Resist copying a large breakpoint scale from another project "just in case."

Naming Conventions for Breakpoints

Semantic, size-based names (sm, md, lg) age far better than device-based names (tablet, desktop), since device categories and their typical sizes shift constantly, while relative size labels stay meaningful indefinitely.

Common Mistakes

• Naming breakpoints after specific devices (iphone, ipad-pro) instead of relative sizes, which quickly become outdated.
• Adding a new breakpoint for every minor layout tweak instead of solving it within the existing scale.
• Defining slightly different breakpoint values in multiple files instead of a single shared map.
• Choosing breakpoints that exactly match specific device widths rather than where your content and layout actually need to adapt.

Key Takeaways

• A sensible breakpoint scale usually has four to six entries, based on real content needs, not specific devices.
• Semantic size-based names (sm, md, lg) stay meaningful longer than device-based names.
• Breakpoints should live in exactly one shared map, referenced everywhere through your responsive mixins.
• Add new breakpoints deliberately, in response to real layout problems, not preemptively.