Common Mobile Viewport Sizes List

The Full Common Mobile Resolutions List by Device Type

Smartphones: Most-Used Viewport Widths and Heights

The phone screen landscape in 2026 is defined by two dominant clusters: the 360px CSS width group (primarily mid-range and budget Android handsets) and the 390–430px CSS width group (dominated by recent iPhone models and high-end Android flagships). Here is a detailed table of popular screen sizes for the most widely deployed smartphones, showing both portrait window dimensions and pixel ratio values. This common screen resolutions reference covers the handsets your audience is most likely using today. Check the resolution name lookup online rather than relying on guesswork or an outdated spec page.

Tablets: Portrait and Landscape Viewport Dimensions

The slate window sits in a uniquely awkward position for adaptive web design: too wide to use phone arrangements, too narrow and variable to match desktop grids. The slate screen most commonly encountered is still the 768×1024 portrait window — a reflection of iPad's long-running dominance in the slate market. Slate models from Samsung and Huawei have pushed alternative sizes into the mix, but iPad resolution remains the reference benchmark for slate arrangement testing. For cross-browser ui testing across slate form factors, the 768×1024 benchmark ensures broad compatibility.

Desktop and Laptop Reference Points for Comparison

While this tool focuses on mobile windows, including computer reference sizes helps you place mobile dimensions in context — and reveals just how concentrated desktop machines are in resolution compared to phones. The top two PC sizes (1920×1080 and 1366×768) together account for roughly half of all PC sessions, while the top five mobile sizes cover only about 35% of mobile usage.

• Computer: 1920×1080 — 1080p monitors, standard laptops; the most common single resolution overall across all hardware
• Computer: 1366×768 — Budget laptops and legacy monitors; still widely deployed in enterprise and education
• Computer: 1440×900 — Mid-range monitors and older MacBook Pro models
• Computer: 2560×1440 — QHD gaming monitors and professional workstations; growing share among power users
• Slate: Hybrid models like the Microsoft Surface Pro present laptop window dimensions (e.g., 1368×912 CSS) in slate form factors, blurring the category boundary
• Smartwatch windows — such as the Apple Watch Series (224×184) and Samsung Watch (180×180) — represent an emerging wearable frontier that web designers rarely account for but that progressive web apps increasingly target

Why Targeting Only the Most Popular Mobile Viewport Sizes Will Break Your Design

The Long Tail of Mobile Screen Sizes and Device Fragmentation

Handset fragmentation is the defining challenge of mobile web development. Unlike the PC landscape — where machines concentrate around a handful of sizes — mobile usage is spread across hundreds of active CSS window widths. The top five common screen resolutions together account for only about 35% of mobile sessions. That means 65% of your mobile visitors are arriving on windows your design may never have been tested against.

Even a window width that holds just 2% of mobile traffic represents tens of millions of broken sessions per month at scale. The Sony Xperia window, Xiaomi window, Vivo window, Motorola window, and Honor window each contribute measurable visits that disappear into that overlooked 65%. Hardware diversity is not a niche concern — it's the baseline reality of mobile web.

What Breaks at Non-Standard Viewports

Common structural issues at the edges of your tested range include:

• Sideways overflow — fixed-width containers that exceed the window width cause content to overflow outside the visible area, forcing users to scroll sideways
• Broken grids — multi-column arrangements that assume a minimum width collapse unevenly at narrow windows, producing misaligned product cards or overlapping text
• Cropped images — images without adaptive width constraints get clipped at the window edge rather than scaling down with the structure
• Navigation collapse failures — a hamburger menu that triggers at 768px may leave users on 360px handsets with an uncollapsed nav bar that consumes the full screen height
• Unreadable text and misplaced icons — small touch targets and overflowing text labels are especially common at high-density screens where logical pixels underestimate the physical output density
• Pixel-level structure shifts — dynamic UI elements like sticky headers, infinite scrolling triggers, and expandable components reposition unpredictably at windows where no explicit behavior has been defined
• Overlapping text — absolute-positioned elements that work correctly at 390px may fall on top of body content at 360px if positioning is calculated in fixed units rather than window-relative ones

Consider this real scenario: a developer confirms their nav bar shows correctly at 390×844 (the standard iPhone 14 window) but discovers it collapses and covers the page hero at the mobile resolution of 360×800 — the most common Android window. Because the developer tested against the most popular iPhone size and skipped the most popular Android size, the bug reached production and affected more than 11% of their mobile audience.

Accessibility Implications of Screen Size Variation

Accessibility is not purely a contrast-ratio or screen-reader concern — it intersects directly with window dimensions. Client zoom levels applied by users with low vision can effectively halve the available window width, turning a 390px arrangement into a 195px arrangement. System scaling on Android handsets can similarly shift the effective logical pixel density. Touch target sizing — recommended at a minimum of 44×44 logical pixels — becomes critical at small windows where a 40px button might be physically indistinguishable from adjacent elements on a high-density screen. Text readability degrades at narrow windows when font sizes are set in fixed pixels rather than rem units, where 1rem equals the client's default of 16px and scales with user font preferences. Thorough cross-device qa testing is the most reliable way to catch these accessibility gaps before users encounter them.

CSS Strategies and Responsive Design Best Practices for Every Viewport Range

Choosing Responsive Breakpoints Based on Real Viewport Data

One of the most persistent front-end development mistakes is setting adaptive thresholds based on hardware names rather than actual window data. Designing your style thresholds around "iPhone" and "iPad" as fixed targets produces brittle arrangements the moment a new form factor ships. Data-driven thresholds — derived from your actual audience's resolution usage — are far more durable.

Your threshold strategy should reflect the window clusters visible in your user data: a mobile-first baseline from 320px, a transition zone at 360–390px covering the bulk of your phone visits, a mid-point at 768px for slate arrangement changes, and a PC threshold at 1024px or 1280px. This content-driven approach to adaptive thresholds outlasts any individual hardware generation.

CSS Strategies That Handle the Full Resolution Spectrum

The second worked example illustrates a critical failure mode: a product listing page built with a fixed-width four-column grid looks pixel-perfect at the common screen resolution of 1920×1080 on a PC, but causes sideways overflow on a 414×896 iPhone because the fixed column widths exceed the available window width. The fix is a fluid grid using grid-template-columns with fractional units and style rules that progressively reduce column count at key thresholds:

/* Adaptive product grid — handles mobile, slate, and desktop windows */
.product-grid {
  display: grid;
  gap: 24px;
  grid-template-columns: repeat(4, 1fr);
}

@media (max-width: 1024px) {
  .product-grid {
    grid-template-columns: repeat(2, 1fr);
  }
}

@media (max-width: 480px) {
  .product-grid {
    grid-template-columns: 1fr;
  }
}

This adaptive product grid pattern uses fractional units that distribute available width evenly regardless of the window width, eliminating sideways overflow at any logical pixel width. The style rules handle the column arrangement transitions at 1024px (slate) and 480px (approaching the mobile threshold), with the single-column stacked arrangement covering all phone dimensions from 320px upward. A well-structured responsive website applies this approach to ensure every user gets a consistent experience.

Style breakpoints should also address content spacing, since padding and margin values that feel generous at 390×844 can consume an uncomfortable proportion of screen real estate at the mobile resolution of 360×800. Use window-relative units (vw, vh) or clamp functions for spacing that scales smoothly across the full size spectrum rather than jumping abruptly at thresholds.

/* Threshold system aligned with real window data */
/* mobile-first baseline: 320px+ */

@media (min-width: 360px) {
  /* Primary Android window — 360x800 baseline */
}

@media (min-width: 390px) {
  /* iOS cluster — 390x844, 393x852 (iPhone 14/15) */
}

@media (min-width: 414px) {
  /* Larger iPhone window — 414x896 */
}

@media (min-width: 768px) {
  /* Slate window — 768x1024 iPad transition */
}

@media (min-width: 1024px) {
  /* Desktop-laptop threshold */
}

@media (min-width: 1440px) {
  /* Wide desktop — 1440x900, 2560x1440 QHD */
}

Ideal Viewport Width Targets for Modern Responsive Layouts

There is no single ideal screen size for an adaptive design — the question itself reflects a legacy mindset from the era of fixed-width arrangements. Modern adaptive design starts from the premise that your structure must be fluid from 320px all the way through 1440px and beyond, with content guiding where arrangement shifts occur rather than hardware names.

That said, if you must prioritize a small set of test widths to optimize speed and arrangement quality, the data points to 390×844 (primary iOS cluster), 360×800 (primary Android cluster), 768×1024 (dominant slate window), and the popular device viewport size of 1366×768 (the most common laptop screen) as the four highest-leverage targets. For teams serving South or Southeast Asian markets, add 360px as an absolute floor since that region's significant mobile resolution share of budget Android handsets makes it non-negotiable. Consistent attention to mobile resolution targets directly improves the overall user experience for visitors on lower-end hardware.

A few things worth noting: average pixel density and logical PPI values matter for image asset strategy. A handset with 460 PPI and 153 logical PPI (like the Apple iPhone 14) has a pixel ratio of 3.0, meaning a 1x image asset will appear visibly soft. Serve 2x or 3x image assets — or use SVG where possible — to maintain visual quality on high-ratio screens without penalizing low-ratio handsets with oversized file downloads.

Automated visual regression checking integrated into your release cycle is the most reliable way to catch size-specific UI issues before they reach production. Tools that compare screenshots across hardware combinations after each deployment catch UI regression issues — pixel-level structure shifts, size-specific UI problems, broken grids — that manual review consistently misses, especially for dynamic content like tracking dashboards, ecommerce homepage arrangements, and product listing pages with complex filter states. This kind of automated approach complements manual cross-device qa testing by ensuring the full range of popular device viewport sizes and common screen resolutions is validated on every release, protecting both user experience and cross-browser compatibility.

For speed engineers, it's worth noting that size differences also drive output speed differences: a handset with a high ratio and a slow network connection will spend significantly more time on image load for unoptimized assets. Use throttling in Chrome DevTools combined with Lighthouse audits to benchmark asset load times across ratio profiles. Lazy loading implementation should also be validated at each threshold, since below-the-fold boundaries shift dramatically between a 360px phone screen and a 1920px PC screen — and what loads eagerly on a large screen may never load at all on a narrow mobile window without careful scroll-depth calibration.