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

A responsive website isn't just a desktop version, a tablet version, and a mobile version strung together. It's a single system capable of reorganizing navigation, content, images, typography, and actions based on the available space.

That is why this guide does not propose one-size-fits-all solutions. It uses practical widths to help you get started with design and QA, but the final behavior should be determined by the content: a menu changes when it no longer fits; a grid changes when its cards are compressed; a line of text is truncated when it can no longer be read comfortably.

Quick answer: Start with 1440 px for desktop, 768 or 1024 px for tablet, and 390 px for mobile. Then try 320, 360, 430, 1280, and 1920 px, as well as all the values in between.

Last technical review: September 2026

The figures in this table are useful reference points for design and testing. They do not represent official standards, nor do they replace ongoing testing between one width and another.

The viewport is the available space in the browser, typically 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 that reading doesn't become a matter of scrolling across the screen from side to side.

In a 1440-px viewport, for example, a container of around 1200 px can accommodate navigation, images, and grids; within it, an editorial column of approximately 640–760 px provides ample space for paragraphs. These are design guidelines, not universal requirements.

A CSS pixel is a browser-defined unit of measurement; it is not necessarily a physical pixel on the screen. A high-density phone may use multiple physical pixels to represent a single CSS pixel. We design the layout in CSS pixels and serve images with sufficient resolution to maintain sharpness.

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

A breakpoint is the point at which the content needs to be rearranged. It shouldn't exist simply because a list defined "tablet" as 768 px. First, we reduce the space, observe where the layout loses clarity, and then make the change.

Adjust the width, change the height, and enable the layers. The mockup page is built using real HTML and CSS: its navigation, hero section, and cards change depending on the simulated space.

"Above the fold" refers to what is visible before scrolling, but it does not correspond to a fixed height. It varies depending on the width and height of the viewport, the browser's dynamic toolbars, zoom level, typography, operating system, and device.

We don't have to put everything at the top. It's a good idea to make the main point clear, provide enough context, include a call to action, and indicate that there's more content below.

On mobile devices, `100vh` may behave unexpectedly when the browser interface appears or disappears. The units `svh`, `lvh`, and `dvh` allow you to distinguish between small, large, and dynamic viewports, although you should always test the results on actual devices.

Starting with a single column forces you to prioritize. When there is enough space, the system can incorporate two or three columns without losing its order. The transition is driven by the needs of the content, not by a commercial label for a phone or tablet.

WCAG 2.2 requires that content be able to reflow to a width equivalent to 320 CSS px without losing information or functionality and without requiring two-dimensional scrolling, except in cases where two dimensions are essential. This test also reveals headings that are cut off, controls that overlap, and floating elements that cover content.

Three cards display properly at 820 px and begin to compress at around 720 px. That point—not the device name—is the reason to switch 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 is placed in a main column, a sidebar, or a reusable module.

A website can use a wide container for navigation, galleries, and card layouts without forcing its paragraphs to span that width. Limiting the editorial column improves the flow, reduces the visual journey, and makes it easier to find the next line.

Typography can also respond flexibly. `clamp()` defines a minimum, a flexible value, and a maximum, preventing unnecessary line breaks. Even so, each extreme must be tested to ensure that long words and headlines do not overflow their space.

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

Auto Layout helps organize positioning, spacing, and alignment. Fill Container fills the available space; Hug Contents preserves the size required by the content; Constraints maintain relationships within a frame; Min Width, Max Width, and Wrap help define boundaries and rearrangement.

The goal isn't to create perfect screenshots. It's to communicate which elements expand, which are restricted, when they wrap, which change order, and which should never be cut off.

Adobe XD was a great tool—just as FrontPage was in its day—and it remains useful for legacy projects. Adobe keeps it in maintenance mode, so anyone starting out today should be aware that it no longer receives active development of new features.

Check out the official Auto Layout guide and the Adobe XD reference.

There's no need to turn every responsive design decision into an endless list of breakpoints. A container with a maximum width, fluid images, and typography with constraints can handle a large part of the system before you even need to add 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 comprehensive system can use `srcset`, `sizes`, and `picture` to deliver appropriate resolutions or cropping. The goal isn't just to download less data—it's to preserve important information when the aspect ratio changes.

A portrait that works on a desktop may need to be cropped differently on a mobile device. If the subject, product, or text is part of the message, responsive images should be considered during production, not after publication.

In our web development and UX/UI services, these decisions are tied to strategy, content, performance, and real-world goals.

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

Development tools speed up QA, but they are no substitute for a real iPhone and Android device. Touch, keyboard, zoom, browser bars, screen density, and performance can reveal issues that a simulation does not show.

Interaction targets need sufficient space. WCAG 2.2 specifies a minimum size of 24 × 24 CSS px for Level AA compliance, with exceptions; designing more user-friendly controls when the context allows it improves the touch experience.

A clear digital strategy helps prioritize which experiences, browsers, and user journeys need the most 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