Screen Sizes & Viewport Cheat Sheet for 2026

Every responsive bug report starts the same way: "it looks broken on my phone." Then you spend ten minutes hunting for that phone's viewport width — one site lists the panel resolution, another lists a viewport from two generations ago, and a third just says "various."

This is the cheat sheet I keep coming back to: the device viewports worth testing in 2026, the framework breakpoints next to them, and the three numbers — resolution, viewport, DPR — that developers constantly mix up. All values below are portrait CSS-pixel references. Treat heights as references, not guarantees: mobile browser bars, keyboards and zoom change the visible height, while width stays comparatively stable.

Phone viewports worth testing

Eleven models cover nearly every width your layout will meet in production, from the narrow 360px Android baseline to the 440px Pro Max class. The full model-by-model reference lives in the iPhone viewport sizes table and the device screen sizes index.

Device	CSS viewport	Panel resolution	DPR
Galaxy S25	360 × 780	1080 × 2340	3
iPhone SE (3rd gen)	375 × 667	750 × 1334	2
Galaxy S25 Ultra	384 × 832	1440 × 3120	3.75
iPhone 14	390 × 844	1170 × 2532	3
iPhone 16	393 × 852	1179 × 2556	3
iPhone 17	402 × 874	1206 × 2622	3
Pixel 10	412 × 923	1080 × 2424	2.625
iPhone Air	420 × 912	1260 × 2736	3
Pixel 10 Pro	427 × 952	1280 × 2856	3
iPhone 16 Plus	430 × 932	1290 × 2796	3
iPhone 17 Pro Max	440 × 956	1320 × 2868	3

Patterns worth internalizing:

• Modern iPhones cluster tightly. Everything from the iPhone 14 to the 17 sits between 390 and 440 CSS pixels wide, all at DPR 3. If your layout survives 390, 402 and 430, it survives the current iPhone line.
• Android is wider at the edges. The base Galaxy line still reports 360px — the narrowest mainstream target, and the one that exposes cramped toolbars and rigid dialogs first.
• DPR is not always a whole number. The Pixel 10 ships at 2.625 and the S25 Ultra at 3.75. Hard-coding "retina = 2x or 3x" assumptions into image pipelines is how blurry hero images happen; serve srcset steps and let the browser pick.
• Shared widths hide differences. Several models share a viewport width while differing in height, DPR and safe areas. A matching reference is a starting point for testing, not proof two devices render identically.

Tablets and laptops, briefly

Tablet viewports overlap small-laptop widths, which is why "tablet layout" and "small desktop layout" so often collide around 1024px.

Device / class	CSS viewport / workspace	Panel resolution
iPad mini (A17 Pro)	744 × 1133	1488 × 2266
Classic iPad reference	768 × 1024	—
iPad (10th gen) / iPad Air 11"	820 × 1180	1640 × 2360
iPad Pro 11" (M4)	834 × 1210	1668 × 2420
iPad Pro 13" (M4)	1032 × 1376	2064 × 2752
Budget laptop (WXGA)	1366 × 768	1366 × 768
MacBook Air 13" (M3)	1470 × 956	2560 × 1664
MacBook Pro 14" (M4)	1512 × 982	3024 × 1964
1080p panel at 125% scaling	1536 × 864	1920 × 1080

Two things to notice. First, laptop "workspace" values are scaled: a 2560 × 1664 MacBook Air panel gives CSS a 1470 × 956 layout space, and OS scaling — not the panel — decides what your media queries see. Second, the classic 768 × 1024 iPad reference refuses to die; it is still a useful portrait test width even though current iPads report larger viewports.

Tailwind vs. Bootstrap breakpoints

Both frameworks are mobile-first min-width systems, but their thresholds only agree at 768px. The side-by-side reference, with a live checker that tracks your current width against both systems, is the responsive breakpoint checker.

Tier	Tailwind	Bootstrap
Base	0–639px (base)	0–575px (xs)
Small	sm 640px	sm 576px
Medium	md 768px	md 768px
Large	lg 1024px	lg 992px
Extra large	xl 1280px	xl 1200px
Largest	2xl 1536px	xxl 1400px

Practical consequences:

• A layout that switches to two columns at Bootstrap lg (992px) does so 32px earlier than the same layout at Tailwind lg (1024px). Porting components between the two without adjusting expectations shifts every boundary.
• Tailwind expresses its thresholds in rem (640px = 40rem at the default root size), Bootstrap in px. If a user changes their browser's root font size, rem-based breakpoints move and px-based ones don't — a classic source of "works on my machine."
• Test the pixel below each threshold, not just the threshold itself: 639, 767, 1023, 1279 and 1535 are where the old layout makes its last stand.

If you only keep one testing set, make it 360, 393, 430, 768, 1024, 1366, 1536 and 1920 — narrow Android, common iPhone, large phone, tablet portrait, tablet landscape, small laptop, large laptop and desktop. The reasoning behind that set is laid out in the common screen resolutions reference.

Check your own device, live

Tables tell you what a device should report. Your actual browser may disagree — because of zoom, OS display scaling, an installed web app shell, or a keyboard eating half the screen. When a bug is on your desk, measure the real thing:

1. Open the viewport size checker on the device in question.
2. Read three values: viewport (window.innerWidth × innerHeight), DPR (window.devicePixelRatio), and the active Tailwind/Bootstrap range.
3. Resize or rotate and watch the values update; then paste the report straight into the bug ticket, so QA reproduces at your width instead of guessing.

For screenshot and image bugs, multiply the CSS slot by the live DPR: a 360px-wide slot on a DPR 3 phone needs a 1080px asset to stay sharp, and exporting at the panel resolution "to be safe" just ships megabytes nobody asked for.

The three numbers everyone confuses

Most screen-size confusion is one paragraph away from disappearing:

Physical resolution is the panel's pixel grid — 1179 × 2556 on an iPhone 16. It describes hardware. Your CSS never sees it directly. CSS viewport is the area the page renders into, in CSS pixels — 393 × 852 on that same phone. Media queries, breakpoints and layout respond to this number and only this number. DPR is the ratio between them: how many physical pixels paint one CSS pixel. It drives image sharpness (and screenshot dimensions), but it does not change which breakpoint is active.

So when a spec sheet brags about a huge resolution, divide by DPR before you panic: what lands in your stylesheet is the viewport. And when a user reports a "tiny" screen, ask for their viewport and DPR — not their panel resolution — before you touch a single media query.

TL;DR

Test widths, not devices: 360–440px covers current phones, 768–1032px covers tablets, and scaled laptop workspaces matter more than panel resolutions. Keep resolution, viewport and DPR in separate mental buckets, verify your own browser live instead of trusting spec sheets, and always check the pixel just below the breakpoint.

Comments

[screensize]

what's the one device that always breaks your layout in a way nothing else does? mine was a galaxy fold and i don't want to talk about it