Common Screen Sizes for Responsive Web Design

There is no universal list of screen widths every responsive site must target. Start with a layout that works at narrow widths, keep it fluid as space changes, and add CSS breakpoints where the content or layout stops working well. Common screen resolutions can help you pick representative test cases, but they are not a breakpoint checklist: CSS media queries respond to the browser viewport, which may differ from a device’s physical screen resolution.

This guide covers common reported resolutions, how to translate them into practical viewport tests, a runnable responsive layout, and ways to inspect screenshots at chosen viewport sizes.

1. Common screen resolutions to use as test cases

Statcounter Global Stats’ worldwide data for September 2026 offers a useful snapshot. These percentages describe reported screen-resolution categories, not CSS viewport widths, installed-device counts, or recommended media-query values.

Scope	Common reported resolutions
Desktop, worldwide, September 2026	1920×1080 (28.07%), 1536×864 (10%), 1366×768 (7.95%), 1280×720 (4.71%), 2560×1440 (3.95%), 1280×1200 (3.64%)
Mobile, worldwide, September 2026	414×896 (13.35%), 360×800 (7.54%), 384×832 (7.1%), 390×844 (6.05%), 393×873 (4.18%), 360×780 (3.39%)
Combined platforms, worldwide, September 2026	1920×1080 (10.71%), 414×896 (8.05%), 360×800 (4.79%), 384×832 (4.58%), 1536×864 (3.81%), 390×844 (3.65%)

The combined-platform percentages mix different devices; for example, 1920×1080 is 10.71% of reported resolutions across platforms, while its desktop share is 28.07%. The mobile and desktop figures have their own platform-specific denominators. Treat all these values as a dated planning aid, not a universal distribution. See the [Statcounter combined-platform data](https://gs.statcounter.com/screen-resolution-stats), [desktop data](https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide), and [mobile data](https://gs.statcounter.com/screen-resolution-stats/mobile/worldwide).

2. Resolution, viewport width, and CSS pixels

A resolution such as 1920×1080 describes physical display pixels. CSS layout generally uses CSS pixels in a layout viewport. High-density displays map multiple physical pixels to a CSS pixel, and zoom or browser configuration can change the effective viewport. On mobile, browser controls also mean the page’s content area does not necessarily match the full physical screen dimensions.

That distinction matters because a media query such as @media (max-width: 600px) checks the viewport width in CSS pixels, not the phone’s advertised physical pixel width. A 414-pixel-wide physical display is therefore not enough information to conclude which CSS breakpoint will apply. [MDN’s viewport guidance](https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_meta_tag) explains why a mobile page needs a correctly configured layout viewport; without it, a wide virtual viewport can make a narrow screen render a scaled-down desktop layout.

For responsive testing, record the width in CSS pixels, height, orientation, and the layout state you expect. Do not copy a physical resolution directly into a media query.

3. Choose breakpoints from the content

Build a layout that can stretch and shrink, then introduce a breakpoint when its content needs a different arrangement. A navigation bar may need to collapse before a card grid changes columns; a form may need a breakpoint at a different width than either. As web.dev puts it, “It’s best to choose your breakpoints based on your content rather than popular device sizes, as those are subject to change with every technology release cycle.” See [web.dev’s media queries guide](https://web.dev/learn/design/media-queries/) and [MDN’s responsive design guide](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design).

Use flexible grids, relative units, and minimum or maximum sizes to keep layouts fluid between breakpoints. MDN recommends relative units for breakpoints, such as em, so zoomed text and user settings are handled more naturally. Media queries also support features beyond width, including orientation and user preferences; add them when the interface has a specific behavior to adapt.

4. A runnable content-led responsive example

Save the following as responsive.html and open it in a browser. It includes the mobile viewport declaration, a flexible content wrapper, a grid that adapts to available space, and a breakpoint chosen to keep navigation and cards readable. The sample values are a starting point for this content, not a prescription for every site.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Responsive layout example</title>
  <style>
    * { box-sizing: border-box; }
    body {
      margin: 0;
      color: #19212b;
      font: 1rem/1.5 system-ui, sans-serif;
    }
    header, main {
      width: min(100% - 2rem, 72rem);
      margin-inline: auto;
    }
    header {
      display: flex;
      flex-wrap: wrap;
      align-items: center;
      justify-content: space-between;
      gap: 1rem;
      padding-block: 1rem;
    }
    nav { display: flex; flex-wrap: wrap; gap: 1rem; }
    nav a { color: inherit; }
    .cards {
      display: grid;
      grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
      gap: 1rem;
      padding-block: 1rem 3rem;
    }
    article {
      min-width: 0;
      padding: 1rem;
      border: 1px solid #ccd3dc;
      border-radius: .5rem;
    }
    img { display: block; max-width: 100%; height: auto; }
    @media (max-width: 42em) {
      header { align-items: flex-start; }
      nav { width: 100%; }
      h1 { font-size: clamp(1.7rem, 8vw, 2.5rem); }
    }
  </style>
</head>
<body>
  <header>
    <strong>Example site</strong>
    <nav aria-label="Main navigation">
      <a href="#overview">Overview</a>
      <a href="#features">Features</a>
      <a href="#contact">Contact</a>
    </nav>
  </header>
  <main id="overview">
    <h1>A layout that follows its content</h1>
    <p>Resize the browser window. The card grid fits the available width, while navigation wraps on narrow screens.</p>
    <section class="cards" id="features" aria-label="Features">
      <article><h2>Flexible</h2><p>Cards fit the available space.</p></article>
      <article><h2>Readable</h2><p>Text and controls keep room to breathe.</p></article>
      <article><h2>Testable</h2><p>Check widths around each layout change.</p></article>
    </section>
  </main>
</body>
</html>

The auto-fit grid handles many widths without a breakpoint. The one media query changes the header treatment when the available width is too small for the preferred arrangement. In a production layout, add a breakpoint only after checking where the content becomes cramped, overlaps, or loses a useful hierarchy.

5. Build a representative viewport test matrix

Do not attempt every possible width. Cover representative widths and the transition points where your design changes. A practical initial matrix can include:

Test case	Example CSS viewport	What to inspect
Narrow mobile	320–360 px wide	Text wrapping, horizontal overflow, tap target spacing, narrow forms
Common mobile widths	360, 384, 390, 393, 414 px	Navigation, card stacking, image scaling, long labels
Between mobile and tablet	600–800 px	Whether grids gain columns cleanly and controls remain comfortable
Tablet or compact window	768–1024 px	Intermediate layouts, sidebars, navigation wrapping
Desktop	1280, 1366, 1536, 1920 px	Maximum content width, line length, whitespace, dense grids
Large display	2560 px wide	Whether content stays bounded instead of stretching too far

These are CSS viewport test suggestions informed partly by common reported resolutions; they are not a claim that a reported physical resolution maps one-to-one to that viewport. Include portrait and landscape where orientation changes the experience. Also drag the browser continuously across breakpoint intervals: a layout that works at 390 and 768 pixels can still fail at 620.

Set the browser viewport in CSS pixels and note orientation.
Check every major layout state: collapsed and expanded navigation, one and multiple columns, forms, dialogs, tables, and media.
Inspect for horizontal scrolling, clipped content, awkward line lengths, overlapping sticky elements, and controls too close together.
Test keyboard focus and text zoom as well as pointer interaction.
Repeat with realistic content, including long names, translated strings, validation errors, and empty states.

Firefox Responsive Design Mode is one browser tool for exploring viewport widths; see [MDN’s guide to responsive design mode](https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_Mode). Browser emulation helps check layout behavior, but it does not replace testing on physical devices for touch, browser chrome, and device-specific rendering.

6. Capture repeatable screenshots at target sizes

Screenshots make visual regressions and layout transitions easier to review. For a repeatable check, choose exact viewport dimensions, keep the same URL and page state, and compare images only after content has finished loading. Browser automation is useful if your project already runs it; for a quick inspection, ScreenshotNeo is a website screenshot API and MCP server for developers. A single request sets a viewport width and height in CSS pixels, so you can capture each test case without installing or maintaining a browser.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -d width=390 \
  -d height=844 \
  -o mobile-390x844.webp

See the [ScreenshotNeo API documentation](https://screenshotneo.com/docs/) for the available parameters. Use your own page URL and API key. Resolution statistics are not viewport recommendations; choose dimensions that correspond to the CSS width you want to inspect and to actual content breakpoints.

7. Or skip the browser setup

ScreenshotNeo accepts one GET request with a URL and returns a clean PNG, JPEG, WebP, or PDF. Set width and height to inspect responsive states. It accepts cookie or consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, and the response identifies the page verdict and billing status in headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

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

With Python:

import requests

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

With Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com',
  width: '390',
  height: '844',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed; an MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots per month with no card, and paid plans start at $5 for 3,000. [Create a free ScreenshotNeo account](https://screenshotneo.com/account/sign-up/) to capture your first responsive states.

8. Options for more focused responsive checks

Once the basic viewport matrix is covered, use capture options to investigate a specific layout issue. ScreenshotNeo supports full-page capture with lazy images loaded, capture of one element by CSS selector, dark mode, 12 device presets or a custom viewport, and retina scale. It can apply custom CSS or JavaScript, click an element before capture, hide selectors, and wait for a selector, a delay, or network idle. These options help make captures repeatable when a page has menus, overlays, or content that appears after interaction. The [documentation](https://screenshotneo.com/docs/) lists parameter names and usage.

For an element that overflows, capture the element as well as the full page to distinguish a local sizing issue from a page-wide problem. Use custom CSS only to isolate the issue; do not treat injected styles as proof the shipped stylesheet is correct. A dark-mode screenshot checks the page’s dark appearance, while a retina capture can help inspect image sharpness. ScreenshotNeo also supports request and resource blocking, custom headers, cookies, user agent, authorization, timezone, and geolocation when a page requires those conditions.

9. Performance, reliability, and cost

For responsive development, reduce the number of screenshots by testing meaningful layout states and breakpoint boundaries instead of every width. Reuse the same test URLs and page state to make comparisons useful. Pages with large images, third-party scripts, or delayed client rendering can take longer to capture; wait for an appropriate selector or network idle where needed, and avoid a fixed delay that is longer than necessary.

In browser automation, run independent viewport captures in parallel only within the resource limits of the browser environment, and keep failures visible rather than silently accepting missing screenshots. For API capture, ScreenshotNeo offers caching with a configurable TTL, asynchronous jobs with signed webhooks, and bulk capture for up to 100 URLs per call. These options can help when screenshot work grows beyond a few manual checks. Its plans are Free: 1,000 shots/month with no card; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; and Business: $249 for 1,000,000. Yearly billing gives two months free, and every feature is available on every plan. For visual QA, remember that a screenshot service checks rendered output; it does not itself prove keyboard accessibility, interaction correctness, or behavior on physical hardware.

10. Troubleshooting responsive layout tests

Symptom	Likely cause	Fix
Mobile layout looks like a tiny desktop page	Missing or incorrect viewport meta element	Set `<meta name="viewport" content="width=device-width, initial-scale=1">` and retest.
A breakpoint does not activate where expected	Confusing physical screen pixels with CSS viewport pixels, or testing a different browser zoom/viewport	Inspect the actual viewport width in the browser and test the media query at that CSS width.
Horizontal scrolling appears at only one width	A fixed-width child, long unbroken text, wide table, or image exceeds its container	Find the overflowing element, allow wrapping or scrolling where appropriate, and constrain media with `max-width: 100%`.
Layout works at preset sizes but breaks between them	Only checking device-like endpoints	Resize continuously through the interval and set a content-driven breakpoint where the current layout fails.
Screenshot differs between runs	Dynamic content, animation, delayed rendering, or changing data	Use a stable page state, wait for a meaningful selector, and disable or account for animations during visual comparisons.
Capture shows a banner or popup	The page displays an overlay, or the relevant cleanup option is disabled	Use a clean capture setup, or explicitly hide/click the relevant element for a diagnostic capture.
Screenshot is blank or incomplete	Navigation failed, content loads late, or a bot check blocks access	Check the page URL and response, wait for the page’s actual content, and inspect the page verdict before treating it as a layout defect.

11. FAQ

What are the mandatory screen sizes every responsive site should target?

There are no mandatory sizes. Choose widths based on where your own content needs to change, then include representative narrow, medium, and wide viewports in testing.

What are common media queries for responsive design?

Common patterns test width with min-width or max-width, but the right query depends on the component and layout. Prefer fluid CSS first, then add queries for specific layout changes.

Should I use a device-name breakpoint list?

No. Device models and viewport configurations change, and many devices share similar CSS widths. Use device presets as convenient test cases, not as the source of your breakpoint strategy.

How often should I update the screen-size statistics?

Resolution shares change over time. If you cite percentages, refresh them from the source and state the month, geography, and platform scope; do not reuse an old snapshot as current data.