Responsive Web Design in 2026: A Guide to Sizes, Dimensions, and Breakpoints for Desktop, Tablet, and Mobile

A responsive website is not a desktop version, a tablet version, and a mobile version stitched together. It is a single system that can reorganize navigation, content, images, typography, and actions based on the available space.

That is why this guide does not propose universal sizes. It uses practical widths as starting points for design and QA, but the final behavior should respond to the content: a menu changes when it no longer fits; a grid changes when its cards get squeezed; a line of text is constrained when it is no longer comfortable to read.

Quick answer: start with 1440 px for desktop, 768 or 1024 px for tablet, and 390 px for mobile. Then test 320, 360, 430, 1280, and 1920 px, along with all the widths in between.

Last technical review: September 2026

The figures in this table are useful checkpoints for design and testing. They are not official standards and do not replace ongoing testing between widths.

The viewport is the available space in the browser, usually expressed in CSS pixels. The content container limits how far the layout can extend within that viewport. The reading width further limits the text column so reading does not mean scanning the screen from side to side.

In a 1440 px viewport, for example, a container around 1200 px wide can organize navigation, images, and grids; within it, an editorial column of approximately 640–760 px keeps paragraphs comfortable to read. These are design references, not universal requirements.

A CSS pixel is a browser reference unit, not necessarily a physical pixel on the screen. A high-density phone may use several physical pixels to represent a single CSS pixel. We design the layout in CSS pixels and serve images with enough resolution to stay sharp.

Presets help us review familiar scenarios, but an interface exists along a continuum. It also has to work at 412, 834, 1180, or any other width between our reference points.

A breakpoint is the point where content needs a different arrangement. It should not exist simply because a list labeled 768 px as tablet. First, we reduce the space, observe where the layout loses clarity, and then introduce the change.

Adjust the width, change the height, and turn on the layers. The sample page is built with real HTML and CSS: its navigation, hero, and cards change based on the simulated space.

Above the fold describes what is visible before scrolling, but it does not correspond to a fixed height. It changes with the viewport width and height, dynamic browser bars, zoom, typography, operating system, and device.

We do not have to fit everything at the top. It does help to make the main value proposition clear, provide enough context, offer an action, and signal that there is more content below.

On mobile, `100vh` can behave unexpectedly when the browser interface appears or disappears. The `svh`, `lvh`, and `dvh` units distinguish between the small, large, and dynamic viewport, though we should always test the result on real devices.

Starting with one column forces you to prioritize. When enough space becomes available, the system can incorporate two or three columns without losing its structure. The transition responds to the content's needs, not a phone or tablet's marketing label.

WCAG 2.2 requires content to reflow at a width equivalent to 320 CSS px without loss of information or functionality and without two-dimensional scrolling, except where two dimensions are essential. That test also reveals clipped headlines, overlapping controls, and floating elements that cover content.

Three cards may have enough breathing room at 820 px and start getting squeezed around 720 px. That moment, not the device name, justifies switching from three columns to two or one.

Media queries respond to the viewport. Container queries allow a component to respond to the width of its own container, which is especially useful when the same card appears in a main column, a sidebar, or a reusable module.

A website can use a wide container for navigation, galleries, and card systems without forcing its paragraphs to span that width. Limiting the editorial column improves reading rhythm, reduces eye travel, and makes it easier to find the next line.

Typography can also respond fluidly. `clamp()` defines a minimum, a flexible value, and a maximum, avoiding unnecessary jumps. Even so, each extreme should be tested to ensure that long words and headlines do not overflow their space.

A practical starting point is to create frames at 1440 for desktop, 768 or 1024 for tablet, and 390 for mobile, and also test 360 and 430. These frames are not independent deliverables: they document how the same system responds.

Auto Layout helps organize direction, spacing, and alignment. Fill Container fills the available space; Hug Contents preserves the size the content needs; Constraints maintain relationships within a frame; Min Width, Max Width, and Wrap help define limits and reorganization.

The goal is not to draw perfect screenshots. It is to communicate which elements grow, which are constrained, when they wrap, what changes order, and what must never be cut off.

Adobe XD was a great tool, just as FrontPage was in its day, and it is still useful for legacy projects. Adobe keeps it in maintenance mode, so anyone getting started today should know that it no longer receives active development of new features.

See the official Auto Layout guide and the Adobe XD reference.

There is no need to turn every responsive decision into an endless collection of breakpoints. A container with a maximum width, fluid images, and typography with limits address much of the system before adding specific rules.

.page-container {
  width: min(100% - 2rem, 1200px);
  margin-inline: auto;
}

img {
  max-width: 100%;
  height: auto;
}

h1 {
  font-size: clamp(2rem, 5vw, 4.5rem);
}

@media (width >= 48rem) {
  .cards { grid-template-columns: repeat(2, 1fr); }
}

.module { container-type: inline-size; }
@container (width >= 36rem) {
  .card { grid-template-columns: 1fr 1fr; }
}

An image with `max-width: 100%` prevents basic overflow, but a complete system can use `srcset`, `sizes`, and `picture` to deliver appropriate resolutions or framing. The goal is not just to download less: it is to preserve important information when the aspect ratio changes.

A portrait that works on desktop may need a different crop on mobile. If the subject, product, or text is part of the message, responsive images should be considered during production, not after publishing.

In our web development and UX/UI service, these decisions connect to strategy, content, performance and real goals.

Chrome, Safari, Firefox, and Edge can differ in typography rendering, form controls, video, sticky positioning, and height units. The dynamic UI in mobile Safari and Chrome also changes the visible viewport as we scroll.

Developer tools speed up QA, but they do not replace a real iPhone and Android device. Touch, keyboards, zoom, browser bars, screen density, and performance can reveal issues that a simulation does not show.

Interaction targets need enough space. WCAG 2.2 sets an AA minimum of 24 × 24 CSS px with exceptions; designing more comfortable controls when the context allows improves the touch experience.

A digital strategy that is clear helps prioritize which experiences, browsers and journeys need more attention.

Last technical review: September 2026.

• MDN Web Docs · Responsive Web Design
• web.dev · Responsive Web Design Basics
• W3C · WCAG 2.2
• W3C · Understanding Reflow
• Figma · Guide to Auto Layout
• Adobe · Adobe XD Learn & Support
• MDN · CSS Container Queries
• MDN · Viewport units
• MDN · Responsive images