Common CSS Breakpoints for Responsive Design

There is no universal set of CSS breakpoints that every responsive site should use. Start with a fluid layout, then add a media query at the width where your content or interface needs a different arrangement. Treat familiar pixel values as design choices to test, not standards for phones, tablets, or desktops.

A breakpoint is a condition in a media query becoming true. It does not inherently identify a device. A navigation bar may need to change at a different width from an article column, card grid, or data table. Choose each threshold to solve a visible layout problem.

1. What are the common CSS breakpoints?

Developers often look for a standard list of phone, tablet, and desktop widths. There is no authoritative list that responsive sites must follow. Device sizes and browser viewports vary, and a layout that works at one named device width can still fail at a nearby width.

Use common values you encounter in a project only as starting points. The useful question is: At what width does this content stop fitting or become harder to use? For example, a navigation row may wrap before an article needs multiple columns. Set those breakpoints independently.

web.dev recommends choosing breakpoints based on content rather than popular device sizes, which can change as technology changes. Its 50em example illustrates one possible threshold for changing a text layout; it is not a universal recommendation or a statistic about sites in use. web.dev: Media queries

2. Build a fluid layout before adding breakpoints

Responsive design can use fluid grids, flexible images, and media queries. Modern CSS layout tools often adapt across available space without a media query, so add one when a deliberate change improves the result, not automatically at every presumed device boundary. MDN also recommends relative units for breakpoints where they suit the design.

• Let content wrap naturally where wrapping remains readable.
• Use flexible tracks and min/max sizing to fit available space.
• Constrain text measure so lines do not grow too long on wide viewports.
• Make images fit their containers instead of assuming a fixed screen width.
• Add a media query when the current layout becomes cramped, awkward, or unnecessarily sparse.

For example, a grid can choose as many columns as fit a minimum card width without a breakpoint:

.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: 1rem;
}

img {
  max-width: 100%;
  height: auto;
}

This is a general pattern, not a fixed design prescription. Adjust the minimum card width and spacing to the content.

3. Choose a breakpoint from the layout’s failure point

1. Start with the narrow layout. Write the base rules so the content works in a single column and at narrow widths.
2. Let the layout stretch. Use flexible sizing and wrapping to cover widths between narrow and wide screens.
3. Find the failure point. Resize the viewport until a component no longer fits, text becomes difficult to scan, or there is too much unused space.
4. Add the smallest useful change. Introduce a query for that component or page at the width where the new arrangement helps.
5. Check both sides. Inspect just below and above the threshold, then adjust the value or transition if the change feels abrupt or the layout still fails.

Here is a complete example of a fluid article measure with a two-column layout at a content-driven threshold:

.article {
  max-width: 70ch;
  margin-inline: auto;
  padding-inline: 1rem;
}

@media (min-width: 50em) {
  .article {
    column-count: 2;
    column-gap: 2em;
  }
}

The 50em value demonstrates media-query syntax and a possible layout change. Whether two columns improve a particular article depends on its content and design. If the text is still too wide in one column or the columns feel too narrow, choose another threshold or keep one column.

4. Write width queries and choose units

CSS supports conditions such as min-width, max-width, and range syntax. A minimum-width query applies styles at and above its threshold; a maximum-width query applies at and below it. Relative units such as em can be a good fit when the layout should respond to text scaling. Use a threshold that you have checked against the content.

/* Apply the wider layout at 50em and above */
@media (min-width: 50em) {
  .layout {
    grid-template-columns: 16rem minmax(0, 1fr);
  }
}

/* Apply a compact navigation style below 42em */
@media (max-width: 42em) {
  .site-nav {
    flex-wrap: wrap;
  }
}

/* Range syntax for a specific middle interval */
@media (40em < width < 70em) {
  .cards {
    gap: 1rem;
  }
}

Use range syntax when it makes the intended interval clearer and matches the browser support requirements of your project. For a component that should simply gain a layout at a minimum width, a min-width query is often easier to maintain.

5. Consider media features beyond width when relevant

Width is common for layout changes, but media queries can test other viewport and user or device characteristics. Use these only when they address a specific requirement; they do not replace content-based width decisions.

Feature	What it can help with	Example
orientation	Adjusting a composition when the viewport is portrait or landscape.	@media (orientation: landscape) { ... }
height or aspect-ratio	Layouts that depend on available viewport height or shape.	@media (max-height: 40em) { ... }
resolution	Some resolution-dependent styling, such as assets.	@media (min-resolution: 2dppx) { ... }
prefers-reduced-motion	Reducing nonessential motion for users who request it.	@media (prefers-reduced-motion: reduce) { ... }
hover and pointer	Adapting interactions to available hover or pointer capabilities.	@media (hover: hover) and (pointer: fine) { ... }

See MDN’s media queries guide for the query system and available features, and MDN’s guide to using media queries for examples. Responsive design fundamentals are covered in MDN’s responsive design overview.

6. Test breakpoints around the transition

Use your browser’s responsive design tools to inspect the page at the threshold and at widths on both sides of it. Check more than the screenshot’s overall appearance:

• Does navigation remain reachable and avoid overlap?
• Do headings, controls, and cards fit without clipping?
• Can users read text without overly long lines or cramped columns?
• Do images preserve their proportions and stay within their containers?
• Does the layout still work when text is enlarged or content is longer than expected?
• Do interactive controls remain usable with touch, keyboard, and the available pointer?

Test the actual width where the content changes, not only preset device profiles. A named device preset can be useful for a quick check, but it does not determine the correct breakpoint for your design.

7. Common breakpoint mistakes and fixes

Problem	Why it happens	Fix
A layout breaks at a width between familiar device sizes.	Queries were chosen from device labels rather than the component’s fit.	Resize continuously, find the failure point, and set a content-led threshold.
Many small media queries accumulate.	Each local issue gets another override without checking whether the base layout can flex.	Use flexible grid, wrapping, and sensible max/min sizing first; retain queries for meaningful changes.
Text columns are too wide on large screens.	The container expands without a readable measure limit.	Constrain line length with a measure such as max-width: 70ch, adjusting for the design.
Mobile styles are overridden unexpectedly.	Overlapping queries, source order, or specificity make multiple rules apply.	Review which conditions match at the affected width and simplify overlapping rules.
A query appears not to work.	The viewport may not be at the expected width, the syntax may be invalid, or another rule may override the declaration.	Inspect matched rules in developer tools, verify the condition and computed style, and check stylesheet loading.
Interaction styles fail on touch devices.	The design assumes every user has hover or a fine pointer.	Keep essential actions available without hover; use pointer and hover queries only for enhancements.

8. Performance, reliability, and cost

Media queries are a normal CSS mechanism for applying conditional styles. For maintainability, keep queries tied to clear layout changes and avoid a breakpoint for every device model. A fluid base layout also covers widths you did not target explicitly. Validate key transitions in browser tools and check the resulting page at intermediate widths.

There is no numeric breakpoint ladder or performance benchmark established by the sources used for this guide. The practical cost is ongoing design and maintenance: more conditional rules mean more states to understand and review. Add a query when the change solves a real fit or usability problem.

9. Capture responsive layouts with ScreenshotNeo

To review how a page looks at a chosen viewport, ScreenshotNeo provides a website screenshot API with device presets and custom viewport support. It can also capture a full page, and its request options include waiting for a selector, a delay, or network idle. See the ScreenshotNeo website and API documentation for request details.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -d viewport_width=800 \
  -d viewport_height=1000 \
  -o responsive-check.webp

Set the viewport options to the width and height you want to inspect; repeat the capture at widths below and above a CSS threshold to compare the transition. Parameter names other screenshot APIs use also work. Use your own page URL and API key.

Or skip the browser setup

One GET request can return a screenshot. The example captures a page; add the viewport options from the ScreenshotNeo docs to check a specific responsive breakpoint.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

• Cookie banners are accepted like a visitor would accept consent, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot. Each step can be turned off.
• Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Response headers report the page verdict and whether the shot was billed.
• An MCP server gives AI agents tools for screenshots, page information, and PDF capture.
• 1,000 screenshots a month are free with no card. Paid plans start at $5 for 3,000 shots; every feature is on every plan.

Create a free ScreenshotNeo account for 1,000 screenshots a month, no card required.

Frequently asked questions

Should I use pixels or ems for breakpoints?

Choose a unit that fits the design. MDN encourages relative units for breakpoint definitions; regardless of unit, the content’s needs should determine the threshold.

Do I need a breakpoint for every device size?

No. Flexible CSS can handle many widths without a query. Add breakpoints for intentional changes where the current layout no longer works well.

Can a breakpoint target a component instead of the whole page?

Viewport media queries evaluate viewport or user/device conditions. For layouts that need to respond to a component’s own available space, consider CSS container queries, which are a separate CSS feature.

Are phone, tablet, and desktop breakpoints wrong?

They can be convenient shorthand for design discussions, but they are not universal standards. Keep the actual CSS threshold connected to the layout problem it solves.