Which Screen Widths Should Your Website Fit? The 6 to Test, From Real Device Data

The 1,080 pixels on a phone's spec sheet do not reach your website: the browser reports a width near 400, and that is the number your layout has to fit.

Short answer: make your site work at every width from 320 to at least 1920 pixels, and check six of them by hand: 320, 360, 440, 768, 1280 and 1920. Then drag the browser window slowly between them and watch for the moment something breaks. Each one is a common width, an edge of the range, or a width a known rule uses, and the dragging catches what a list of devices misses.

What does "screen width" mean for a website?

It means the width in CSS pixels, not the hardware pixels on the box. Three terms cover everything in this post:

CSS pixel

The unit your layout is measured in. Device pixel ratio is how many hardware pixels stand for one CSS pixel, so a 1,080-pixel-wide panel at a ratio of 3 reports 360.

Viewport

The part of the browser that shows your page. On most phones it is the whole screen; on larger monitors it is the size of the browser window, which can be much narrower than the screen.

Breakpoint

The width at which your CSS changes the layout, such as moving from one column to two.

Which widths do visitors actually have?

Most listed screens sit in two bands: phones from 360 to about 430 pixels, and desktops and laptops from 1280 to 1920. These figures come from StatCounter for October 2025 to September 2026.

The split changes with your market. Phones averaged 52.3% of page views worldwide over those 12 months, against 46.3% for desktop and 1.5% for tablets. In the US, desktop led with 54.5% to 43.4% for phones, and in Europe it was 50.5% to 47.3%. The share also swings by up to about 10 points between months: phones went from 49.3% worldwide in August 2026 to 59.1% in September, and led in all three that month. StatCounter's pages open on that latest month, so its numbers will not match these 12-month averages. The leading phone width changes too:

Read these rows with care. 1536 x 864 is exactly 1920 x 1080 divided by 1.25, which fits a 1080p laptop at 125% display scaling. StatCounter also lists 800 x 600 and 1280 x 1200 under desktop, at 6.0% and 6.3% worldwide, and does not say why; 1280 x 1200 is over half of the worldwide 1280 figure. Neither is a normal laptop size, so we would not design for them, but they are one more reason not to assume "desktop" means wide. StatCounter does not publish how it reads the size, but these rows look like full screens in CSS pixels (what screen.width returns), not browser windows.

Your own analytics beat any world table. If your site records screen sizes, compare your top rows with these and move the checks below to match.

Which six widths should you test?

Each width below has a reason, either a real audience or a rule to meet. Between them they cover the narrowest size you must support and the top worldwide phone, tablet and desktop widths.

Why is a list of devices not enough?

Because visitors do not arrive in six sizes. A person with a 1920 screen who snaps the browser to half of it is at 960, a width few device lists include. web.dev says it plainly: "It's best to choose your breakpoints based on your content rather than popular device sizes", because those sizes change with every release cycle. A layout should change where it starts to look wrong, whatever the width happens to be.

You can feel this in the box below. Drag its bottom-right corner, then read the ruler. The small site inside changes at 420 and 600 pixels of its own width, not at the width of any phone.

Many sites inherit their breakpoints from a theme or framework. In the 2022 Web Almanac, 57% of pages used a min-width of 768 and 51% a max-width of 767, so the seam between those two numbers is worth checking on its own. Bootstrap's other defaults are 576, 992, 1200 and 1400; Tailwind's are 640, 1024, 1280 and 1536.

How do you test a website at these widths?

1. Check the viewport tag first. View the page source and look for <meta name="viewport" content="width=device-width, initial-scale=1">. 95.2% of mobile pages have a viewport tag (2025), but without one, some mobile browsers lay the page out at a typical 980 pixels and shrink it, and your small-screen breakpoints may never run.
2. Open device mode. In Chrome, open DevTools and switch on the device toolbar. Choose Responsive and type a width.
3. Walk the six widths on your key pages. Use the home page, a service or product page, the contact form and your longest page. At each width, look for a sideways scrollbar, cut-off text, and buttons that overlap or sit too close.
4. Drag slowly between them. Pull the width from 320 up to 1920 and stop wherever the layout jumps or looks cramped. Write down that width.
5. Zoom to 400%. On a 1280 window, browser zoom at 400% gives you the 320 case with real text, and the page should still read top to bottom.
6. Finish on a real phone. Chrome calls device mode "a first-order approximation" and says that when in doubt, you should run the page on a real device. Fill in your form with your thumb.

What usually breaks, and how do you fix it?

Most faults come from something with a fixed size. Hand this list to whoever maintains your site.

• The page scrolls sideways on a phone. Usually something has a fixed width, or a long unbroken string or 100vw pushes past the edge. Find it and add max-width: 100% to images and boxes. Give wide tables their own scrolling wrapper.
• The menu wraps onto two lines around 1280. Move the breakpoint for the collapsed menu up to the width where the items stop fitting.
• A full-screen hero hides its button on phones. vh follows the large viewport, so a browser's address bar can cover the bottom. Use svh, which always leaves room for it. dvh follows the bar as it moves, but MDN warns it can resize content during scrolling.
• Buttons are hard to hit. WCAG 2.5.8 (Level AA) asks for 24 by 24 CSS pixels with some exceptions, WCAG 2.5.5 (Level AAA) for 44, Apple for 44 by 44 points and Android for 48 by 48 dp. Aim for 44 or more. Expecting 48 pixels and 8 pixels between targets, the Web Almanac's last Mobile Web chapter, from 2022, found only 42% of mobile sites had sufficient tap targets.
• Text runs edge to edge at 1920. Set a maximum width on the text column; our guide to readable text has the numbers.
• Pictures look soft or load slowly on phones. Serve several sizes, in the right file type for each picture.

What do website owners get wrong about screen sizes?

What should you check before calling a page finished?

• No sideways scroll at 320, 360 or 440
• Page still reads at 400% zoom on a 1280 window
• Menu works at 767 and 768
• Nothing wraps oddly at 1280
• Text column stops growing well before 1920 (about 75 characters a line)
• Buttons and links are easy to tap, 44 pixels or more where you can
• Main button stays visible with a phone's address bar showing
• Contact form completed on a real phone

Accessibility overlaps with most of this list. Our accessibility fix list covers the errors that testing for width will not find.

Common questions about website screen sizes