Screen sizes & breakpoints reference

Three numbers people mix up

Every screen has a physical resolution (the pixels on the panel), a device pixel ratio (how many of those pixels make one CSS pixel) and a CSS viewport (the size your layout actually gets). Only the last one matters to your media queries. The formula is simple:

CSS pixels = physical pixels ÷ device pixel ratio

An iPhone 17 Pro has a 1206 × 2622 panel at 3x, so it reports 402 × 874. A Galaxy S25 Ultra is a trickier case: its panel is 1440 × 3120, but out of the box it renders at 1080 × 2340 with a ratio of 2.8125, so websites see 384 × 832. That is why this reference lists the viewport first and the resolution second.

Screen size is not the space you get

The viewport numbers in the table are the full screen. In a real browser the address bar, tab bar and system UI take part of the height, and on mobile that amount changes as the user scrolls. Two practical consequences:

• Use the viewport meta tag. Without <meta name="viewport" content="width=device-width, initial-scale=1"> mobile browsers lay the page out at about 980px and shrink it, and none of these sizes apply.
• Prefer dvh/svh to 100vh. On mobile, 100vhis the height with the toolbars hidden, so a “full-screen” hero gets cut off. 100svh fits the smallest viewport and 100dvh follows the toolbars as they move.

The ranges that matter in 2026

How to choose breakpoints

Do not chase devices. New phones arrive every few months and their widths cluster tightly, so a breakpoint at exactly 402px helps nobody. Work mobile-first instead: write the base styles for a 360px screen, then add min-widthbreakpoints where the content needs more room. Tailwind's defaults (640, 768, 1024, 1280, 1536) are a good scaffold because each one falls in a gap between device groups rather than on top of a popular size.

• Test between breakpoints, not on them. Layouts tend to break at 700 or 1100px, where nobody looked.
• Cap line length. Text wider than about 75 characters is hard to read, so give content a max-width and let big screens add margin.
• Scale type fluidly with clamp() rather than jumping at each breakpoint. The fluid type scale generator writes the values.
• Use container queries for components that appear in both narrow sidebars and wide grids. The card should respond to its column, not the window.

Pixel ratio and images

High-DPR screens need bigger image files to look sharp. A hero shown 400px wide on a 3x phone needs a 1200px source. Use srcset with width descriptors and an honest sizes attribute so each device downloads only what it needs, and use SVG for logos and icons so they are sharp at any ratio. In practice 2x covers most photos well; the jump from 2x to 3x is hard to see and costs far more bytes.

Common mistakes

• Designing desktop-first at 1440px and squeezing it onto phones at the end.
• Using physical resolution (1206px) where you meant CSS width (402px).
• Testing only on your own phone. Check 360px, 390px and a tablet at minimum.
• Forgetting landscape phones, which are roughly 670–1,000px wide and land on tablet breakpoints.

Want to see a design inside real hardware? Drop a screenshot into the device mockup generator. More on the approach in the responsive design glossary entry, and if you would rather hand the whole job over, I design and build for every one of these screens in my website design and mobile app design work.