All articles
Responsive CSS

CSS Breakpoints: A Complete Guide

How to choose, name, and test CSS breakpoints based on content instead of devices - with a practical workflow for verifying every transition.

8 min read - Updated 2026-06-15

Use this guide as a compact release reference, then validate the same breakpoints in Sizzy with synchronized devices and screenshot evidence.

Stop designing breakpoints around devices

The biggest mistake in responsive CSS is picking breakpoints to match specific phones. New devices ship every year, and chasing pixel-perfect parity with a 2019 iPhone is a losing game. Instead, let the content decide: add a breakpoint at the exact width where the layout starts to look cramped, awkward, or broken. This produces fewer, more meaningful breakpoints that hold up across every device class.

Resize slowly and add a breakpoint where the layout actually fails

Aim for 3-4 well-chosen breakpoints, not a dozen device presets

Name breakpoints by intent (sm, md, lg) not by device

Document why each breakpoint exists so the team can maintain it

A sensible default breakpoint scale

Most projects converge on a similar scale because content reflows at similar widths. Use these as a starting point, then adjust to your actual layouts. The key is consistency: define the scale once in your design tokens or framework config and reuse it everywhere so you never hardcode magic numbers in component CSS.

640px for small tablets and large phones in landscape

768px for the tablet layout handoff

1024px for small laptops and desktop sidebars

1280px and up for wide desktop layouts

Verify every breakpoint transition

A breakpoint that looks fine at the exact threshold can still break 10px on either side. The only reliable way to catch this is to view the layout across multiple widths at once and scrub through the transition. A multi-device browser like Sizzy shows phone, tablet, and desktop side by side and keeps them in sync, so you see all breakpoint states without resizing a single window.

Check 20px below and above each breakpoint, not just the threshold

Watch for content jumps, overflow, and text reflow at the boundary

Test with real copy and authenticated UI, not placeholder text

Capture screenshots at each breakpoint for the release record

Release checklist

Every breakpoint maps to a real layout change, not a device.

The breakpoint scale lives in one config and is reused everywhere.

Each transition is tested 20px on both sides of the threshold.

Release screenshots cover the riskiest breakpoint transitions.

Frequently asked questions

How many CSS breakpoints should I use?

Most sites need only 3-4 breakpoints. Add one wherever the content genuinely breaks rather than matching specific devices. Fewer, content-driven breakpoints are easier to maintain and hold up better as new devices ship.

What are the most common CSS breakpoint values?

640px, 768px, 1024px, and 1280px are common defaults and match the scales used by Tailwind and Bootstrap. They reflect where content typically reflows rather than exact device widths, so they generalize well.

Should breakpoints be in px, em, or rem?

Using em or rem for media queries respects the user's browser font-size setting, which improves accessibility. Pixels are simpler and more predictable. Many teams use rem-based breakpoints for this reason, but consistency matters more than the unit.

Related guides