Standard Screen Sizes for Web Design

There is no single screen size that is “standard” for every website. The practical approach is to design a flexible interface system, use a few representative canvases for making decisions, and continuously test every width between them. A useful starting set is 360 or 390 CSS px for mobile, 768 CSS px for tablet, and 1280 or 1440 CSS px for desktop. You should also verify reflow at 320 CSS px and behavior on a wide screen around 1920 px. These figures are reference points, not a list of devices to target. This guide explains CSS pixels versus hardware resolution, content-led breakpoints, containers, grids, gutters, Figma-to-code handoff, and responsive testing without tying the interface to one phone or laptop model.

What screen sizes should you use for web design?

The short answer is to create at least three representative frames and test two additional boundaries. Design the primary mobile state at 360 or 390 CSS px, tablet at 768 CSS px, and desktop at 1280 or 1440 CSS px. Then inspect 320 CSS px for horizontal overflow and about 1920 CSS px to ensure that content does not stretch excessively. When an existing website's analytics shows that other viewports dominate, prioritize the real audience data.

Do not hand over a single 1440 desktop file and ask developers to “make it responsive.” Every important component needs a rule for growth, shrinkage, column stacking, wrapping, visibility, and maximum width. Our responsive web design guide covers Flexbox, Grid, media queries, and implementation techniques; this article concentrates on dimensions and handoff decisions.

How do CSS pixels, screen pixels, and the viewport differ?

In web design, 390 generally represents CSS pixels in the viewport, not the number of physical pixels in a phone panel. A device may have a very high hardware resolution and device pixel ratio while its browser reports a viewport only a few hundred CSS pixels wide. CSS pixels are density-independent, allowing text and controls to retain usable logical sizes across displays with different densities.

The viewport is the browser area used to lay out web content. It can be smaller than the display because of browser chrome, a split window, a sidebar, or zoom. A visitor with a 1920-pixel laptop display does not necessarily view the website in a 1920-pixel viewport; the browser may occupy half the display. That is why a breakpoint should not be treated as a device name.

MDN's viewport documentation explains that older mobile behavior may use a virtual viewport around 980 px wide and then scale the page down. Declaring width=device-width tells the browser to align the layout viewport with the device width in CSS pixels:

<meta name="viewport" content="width=device-width, initial-scale=1" />

In Figma, a 390 px frame can represent a 390 CSS px reference in the handoff, but bitmap assets still need adequate density. Do not double the entire layout to 780 because a device has DPR 2. The design retains logical dimensions; the image pipeline or srcset supplies an asset suitable for the display density.

How should you choose mobile, tablet, and desktop frames?

A frame shows the designer's decision at a representative width. A breakpoint is the condition at which CSS changes a layout. They are related but not identical: a handoff may contain three frames while the implementation uses two, three, or four breakpoints depending on its components. The states between the supplied frames must not be left undefined.

Choose frames after understanding the page type, data, and traffic source. A dashboard with a sidebar, table, and filters needs different intermediate states than a one-column landing page. A store must test long product names, filters, and the cart; an editorial site must control line length. For an existing website, use viewport analytics to select references for real audience groups rather than copying tool presets.

Mobile: use 360 or 390 CSS px as the primary design

A 360 px canvas is compact and exposes long headings, rigid cards, and crowded actions early. A 390 px canvas is close to many current phone viewports and provides slightly more realistic room. Select one as the primary frame, but continuously resize from 320 to approximately 480. Mobile-first design does not mean shrinking desktop. It forces the team to decide content order, the main CTA, and critical states first. Horizontal padding of 16–20 px is a useful starting range, but should adapt to the brand and components instead of becoming a mandatory constant.

Tablet: use 768 CSS px to inspect the intermediate state

Tablet is often omitted because teams only hand over mobile and desktop. Yet the intermediate range is where navigation, three-column cards, forms, and tables frequently break. A 768 px frame is a convenient reference, but test portrait, landscape, and narrowed browser windows too. The layout does not have to become a smaller desktop. A sidebar may become a drawer, three columns may become two, and filters may open in a sheet. Let content space—not the “tablet” label—drive the decision. Record the transition explicitly for implementation.

Desktop: use 1280 or 1440 CSS px with a content max-width

1280 works well for laptop-oriented design and discourages over-wide layouts; 1440 gives more room for a grid, hero image, or dashboard. In either frame, content commonly sits inside a container limited to roughly 1120–1280 px depending on the project, while backgrounds can extend edge to edge. Text stretching across 1440 or 1920 becomes difficult to read and weakens relationships between groups. The handoff must specify max-width, minimum padding, and behavior beyond the design frame. Test narrower laptop windows as well.

Wide displays: test at 1920 CSS px instead of stretching everything

On a wide display, the container usually stays constrained and centered. Only backgrounds, decorative assets, or intentionally immersive sections span the full width. Check that the hero does not produce meaningless empty space, imagery remains sharp, modals do not grow excessively, and content retains focus. A dashboard or map may use more workspace while forms and paragraphs remain bounded. A 1920 px viewport is a useful QA point, not necessarily a separate full design deliverable. Also inspect ultrawide whitespace and background cropping.

Choose breakpoints from content, not device names

A good breakpoint appears when the current layout loses quality: navigation runs out of space, cards become narrow, a heading wraps poorly, a table becomes unreadable, or whitespace grows unreasonable. web.dev recommends starting small, expanding the viewport, and adding a breakpoint when the content genuinely needs a change instead of following a phone brand or operating system.

The workflow has four steps. First, build the smallest layout with real content. Next, widen the viewport until the components become too sparse or there is room for a more useful structure. Place a breakpoint around that transition, then inspect a few pixels on both sides. Finally, repeat with long data, errors, zoom, and another language when the site is multilingual.

Values such as 640, 768, 1024, 1280, and 1536 px are familiar starting points in frameworks, not universal web standards. A simple site may need only two breakpoints; a complex dashboard may need more. Every additional breakpoint increases test effort and can produce conflicting overrides. Prefer fluid behavior using Flexbox, Grid, minmax(), clamp(), and flexible containers. Introduce a breakpoint when the structure truly changes.

What container, grid, and gutter sizes should you use?

The container controls content width, the grid establishes column relationships, and gutters keep space between columns and viewport edges. No single numeric system fits all products, but a consistent starting system helps Figma and CSS use the same language. Do not confuse a 1440 frame with a 1440 content container: the frame represents the viewport while the content is commonly narrower.

These are starting suggestions, not WCAG or SEO criteria. An editorial site may use a 640–760 px reading column inside a large container; a dashboard needs more data space; a landing page may have full-bleed sections while its text remains constrained. A 4 or 8 px spacing scale reduces arbitrary values, while still allowing justified exceptions. Record named tokens such as container-lg, space-6, and gutter-md instead of isolated measurements on every frame.

What decisions belong in responsive UI/UX design?

Responsive design is more than changing a column count. A sound UI/UX system preserves information order, function, and meaning as space changes. Every component needs rules: how far it can grow or shrink, when it wraps, when the arrangement changes, which information takes priority, and how interaction states work for mouse, keyboard, and touch. Before drawing each breakpoint, list high-risk components: long navigation, variable-data cards, multi-field forms, tables, modals, text over imagery, and sticky regions. Test them with unusually short and long content. This turns “responsive” from a final-file note into requirements the team can inspect, implement, and accept. It also exposes components that need a container-driven rule rather than another page-level breakpoint.

Typography and line length

Use a bounded type scale rather than allowing text to grow indefinitely with the viewport. clamp() can make headings scale fluidly between a minimum and maximum, but you still need to test Vietnamese diacritics, long titles, and browser zoom. Give body copy a max-width measured in characters or rem so it does not run from edge to edge on desktop. Line height, paragraph spacing, and hierarchy must remain clear on mobile. Never turn text into an image merely to preserve the mockup's line breaks.

Buttons, links, and touch targets

On small screens, visible size and interactive area need not be identical, but users must still activate a target accurately. WCAG 2.2 Target Size (Minimum) requires at least 24×24 CSS px or sufficient spacing under its exceptions; important controls generally benefit from being larger than the minimum. Inspect icon-only buttons, modal close controls, pagination, and adjacent links. Provide focus, hover, active, disabled, and loading states. Test primary tasks one-handed on a physical phone and confirm that sticky controls do not cover other targets.

Images, video, and graphic assets

The design should document aspect ratio, focal point, and cropping behavior rather than simply placing one bitmap in a frame. HTML can use srcset and sizes so the browser chooses an asset for the rendered slot and screen density. MDN's responsive image guide explains this selection process. Supply a sufficiently large image for the maximum display size while compressing it sensibly. Use SVG for logos and icons where appropriate, and provide width and height so the browser reserves space and reduces layout shifts. Test missing-image and loading-failure states too, especially when text or controls depend on the asset's contrast.

Navigation, forms, tables, and difficult content

Desktop navigation may become a menu button on mobile, but its destinations and order should remain complete. Multi-column forms generally collapse into one column; labels must not exist only as placeholders. Data tables need a deliberate strategy: a scrollable table region, priority columns, row cards, or a detail view—not microscopic text. Charts, maps, and editors are examples that may require controlled two-dimensional scrolling. Design empty, error, loading, and long-content states because those are where the ideal dimensions usually fail. Confirm keyboard order after visual rearrangement and make hidden navigation easy to close without losing focus.

From Figma to HTML, CSS, and JavaScript

Figma describes intent; the browser calculates the final layout from HTML, CSS, content, and the viewport. HTML5 provides semantic structure such as header, nav, main, section, form, and table. CSS owns dimensions, spacing, grids, typography, media queries, and display states. JavaScript manages behavior such as navigation drawers, modals, carousels, and dynamic data; it should not patch a layout that CSS can solve naturally. PHP or another server framework creates HTML and data, while responsive breakpoints remain primarily a CSS concern.

A handoff should not say only “desktop 1440, mobile 390.” For each template and component, provide tokens, max and min widths, auto layout, wrapping rules, structural breakpoints, states, and boundary-content examples. If a developer must measure every gap by eye or guess the mobile order, the design package is incomplete.

Read about the role of HTML and the role of CSS if you need the foundations before handoff. Our Figma and Canva web interface guide explains the broader wireframe, component, and prototype workflow.

A screen-size testing matrix

It is impossible to test every device, but a small matrix can cover the main failure classes. Test fixed viewports, continuously resize across breakpoints, zoom, use physical devices, and insert boundary data. Browser DevTools supports fast repetition; real devices reveal virtual keyboards, browser bars, safe areas, touch behavior, and performance that emulation does not fully reproduce.

WCAG 2.2 Reflow requires vertically scrolling content to work at a width equivalent to 320 CSS px without losing information or functionality and without two-dimensional scrolling, except where two-dimensional layout is essential. This is an accessibility criterion, not a claim that every user owns a 320 px device. When reporting a problem, record the viewport, browser, zoom, reproduction steps, expected result, and actual result so the fix can be reproduced and verified.

Eight principles for choosing sizes and designing responsively

A resilient interface follows eight principles. First, content determines breakpoints, not device names. Second, design from small to large to settle priorities early. Third, prefer fluid layouts before media queries. Fourth, constrain content width instead of stretching text across the display.

Fifth, components have their own rules: a card may wrap at a different width from navigation. Container queries allow styling by the containing area rather than the entire viewport. MDN explains that @container resembles a media query but tests the container. Sixth, design with boundary data, including long text, missing images, errors, and empty states. Seventh, do not block zoom or hide mobile functionality. Eighth, test continuously between frames, not only on three polished screenshots.

These principles matter more than memorizing a size chart. When a new device appears or a window is split, a rules-based layout adapts while a model-specific layout adds another exception. A strong web interface is not “correctly sized” in three pictures; it preserves hierarchy, functionality, and readability across the range.

Do screen sizes make a website SEO-friendly?

Responsive behavior contributes to user experience and accessibility, but it is not the whole meaning of SEO-friendly web design. A website can look correct at 390, 768, and 1440 while lacking useful content, titles, canonicals, internal links, a sitemap, or adequate speed. Conversely, complete metadata cannot rescue a page with horizontal overflow, difficult controls, and hidden mobile content.

When dimensions are managed well, visitors can read and interact more easily, and one URL can serve the same content instead of maintaining a separate mobile version. Responsive images avoid downloading assets far larger than the rendered slot. Declared image dimensions reserve space, while fluid layouts reduce breakage at unfamiliar viewports. These qualities support technical quality and experience, but should not be presented as a ranking guarantee.

Our guide to SEO-friendly website design covers structure, metadata, crawling and indexing, performance, and content. In a real project, review responsiveness with technical SEO and accessibility instead of leaving three separate audits until the final day.

Frequently asked questions about web design screen sizes

These answers address common confusion between Figma frames, CSS breakpoints, device resolution, and asset dimensions. The figures are practical starting references rather than universal standards; final decisions must follow project content, analytics, accessibility needs, and implementation data.

Should a desktop website be designed at 1366 or 1440 px?

Both can work. A 1440 frame is convenient for design and grid systems, while 1366 represents many older laptops. A practical choice is to design at 1440 with a 1200–1280 container, then verify 1280 and 1366. If the interface only looks good at precisely 1440, it is not responsive. Do not make text or forms fill the whole frame simply because space remains.

Should mobile design use 360 or 390 px?

Choose one based on audience data or team convention; both are sensible. A 360 frame creates useful pressure for narrow content, while 390 resembles many modern viewports. More importantly, test continuously from 320 to 480 and avoid locking components to one phone. When analytics exists, choose a primary frame near a common group while retaining the narrow boundary test. Include long labels and validation messages in that test.

Are 768, 1024, and 1440 standard breakpoints?

No. They are familiar reference values, not mandatory standards. A breakpoint should be introduced when content or a component requires a layout change. Framework tokens can improve consistency, but still need testing with real content. Do not add a breakpoint for every device; an excessive set makes CSS harder to maintain and expands the QA matrix. Prefer a small documented set, adding component-specific rules only when evidence demands them.

Do you need a mockup for every screen width?

No. You do not need dozens of frames, but the rules between frames must be documented. A typical handoff includes mobile, tablet when it has a distinct state, desktop, component states, and responsive notes. Complex regions such as navigation, tables, dashboards, heroes, or forms may need additional examples. Developers still test every width, and designers should review the working implementation rather than approving only screenshots at preset sizes.

What size should a hero image be exported at?

There is no universal size because rendered slots, aspect ratios, and focal points differ. Determine the largest display size, prepare a source sharp enough for higher densities, compress it, and deliver multiple candidates through srcset or an image CDN. Mobile may need art direction or a separate crop rather than the same huge desktop image. Always declare its aspect ratio or width and height, then test overlaid text across viewports.

How does the three-layer model relate to responsiveness?

In a common explanation, the presentation layer owns the responsive interface, the business layer handles logic, and the data layer stores and retrieves information. Data from the latter layers still affects layouts: long names, empty states, errors, and permissions can change components. Designers and front-end developers therefore need content limits and data states agreed with the back end instead of testing only ideal placeholder content.

Conclusion: design a range, not three screenshots

Frames at 360/390, 768, and 1280/1440 CSS px form a useful starting set, with 320 and 1920 as valuable test boundaries. Quality, however, does not come from selecting one correct number. It comes from container, grid, wrapping, breakpoint, max-width, boundary-data, and component-change rules across the full viewport range.

Agree on frames with developers, use CSS pixels as the shared language, introduce breakpoints where content fails, and review the running site on physical devices. Keep the viewport matrix and boundary data with the design system so later releases can repeat the same acceptance checks instead of rediscovering old defects. If your project already has a UI file but lacks a clear grid, breakpoints, tablet states, or handoff notes, RiverLee can review the components and recommend a responsive system before development begins. Contact +84 962 334 807 for a scope assessment. If your goal is to learn implementation techniques, start with the responsive guide linked near the beginning.