Responsive web design is a way of building pages so that one layout adapts to any screen. Three ingredients make it work: a viewport declaration, fluid proportions in place of fixed widths, and breakpoints where the layout changes shape.
It underpins almost every set of web design templates in use today, and it changes how designs are drawn and presented. This page explains each ingredient, how to choose breakpoints, and the mistakes that cause horizontal scrolling and unreadable text.
What responsive layout means in practice
The term comes from Ethan Marcotte. In web.dev’s words, responsive web design, “originally defined by Ethan Marcotte in A List Apart”, is a design strategy that responds to users’ needs and their devices’ capabilities by changing a site’s layout to suit the device being used. The same article gives a simple picture: a responsive site might show content in a single-column view on a phone, two columns on a tablet, and three or four columns on a desktop computer.
MDN describes the approach as a default rather than a specialty. Responsive design, it says, refers to a site or application design that responds to the environment in which it is viewed, and the web has moved to the point where a desktop version simply scaled down is unusual. For a designer, that shifts the deliverable. A single desktop screen is no longer a finished design. A layout is a set of rules about how content rearranges as space changes.
Start with the viewport
Nothing else works until the page declares how wide it expects to be. Without that declaration, phones fall back to a legacy behaviour. web.dev explains that mobile browsers render the page at a desktop screen width “usually about 980px”, then shrink the result to fit. Text looks inconsistent and visitors have to zoom to read or tap anything.
The fix is one line in the document head. MDN states that “The recommended setting is the following, which sets the viewport to match the device’s width”, and the value it gives is width equals device-width. Once that is in place, the layout can respond to the real width of the screen, and the CSS pixel stops being a guess.
The viewport tag also offers controls for minimum and maximum zoom. Designers should leave them alone. web.dev advises: “We don’t recommend using these attributes because they can prevent the user from zooming the viewport, potentially causing accessibility issues.” This lines up with a W3C requirement that text can be enlarged without breaking the page. The Understanding document for the Resize Text criterion says content satisfies it if it can be “scaled up to 200%” using at least one text scaling mechanism supported by user agents, which a layout that locks zoom cannot honour.
Fluid grids and flexible media
A fixed pixel width is the opposite of responsive. Fluid layouts size columns in proportion to the space available, so they stretch and shrink smoothly between breakpoints. CSS Grid has a unit built for this. MDN explains that “The fr unit represents a fraction of the available space in the grid container.” A three-column design in which each track takes one fraction of the space stays balanced on any container width, with no breakpoint needed.
Media needs the same treatment. An image that has a fixed width wider than the screen forces the page to scroll sideways, and web.dev is blunt about the cost: “Forcing the user to scroll horizontally or to zoom out to see the whole page causes a poor user experience.” Designers can prevent this by drawing images and cards that scale with their column and by giving the developer the intended aspect ratio, not a single pixel size.
Flexbox and Grid solve different layout problems, and each deserves its own guide. For this page, the point is that both express layout as relationships between boxes rather than as coordinates, which is what makes them suitable for unknown screen sizes.
Choosing breakpoints
A breakpoint is the point at which a media query takes effect and the layout changes. MDN’s responsive design guide explains that a common approach is to create a simple single-column layout for narrow-screen devices, then check for wider screens and implement a multiple-column layout when there is enough width, and that designing this way is known as mobile first design.
The same guide gives the most useful rule for picking the points themselves: “best practices encourage defining media query breakpoints with relative units rather than absolute sizes of an individual device”. In plain terms, do not build a breakpoint for a particular phone model. Build one at the width where the content itself starts to look wrong.
A practical way to find those widths:
- Start with the narrowest layout, one column of content in reading order.
- Widen the window slowly and note where lines get too long, columns look sparse or gaps grow awkward.
- Add a breakpoint at each of those points and change only what needs changing there.
- Express the widths in relative units so they scale with the reader’s text size settings.
Query syntax itself is a developer topic, and a media query guide covers it. A designer’s job is to supply the content-driven decisions: which elements stack, which move, and which are hidden or replaced on small screens.
Fluid type and spacing without extra breakpoints
Breakpoints are not the only tool. Some values can scale continuously. The CSS clamp function takes a minimum, a preferred value and a maximum, and MDN says it “clamps a value within a range of values between a defined minimum bound and a maximum bound”. Applied to a heading size, it lets text grow with the window but never drop below a readable floor or balloon past a sensible ceiling. MDN notes the function has been available across browsers since July 2020, so it is established enough for production use.
The same idea works for padding and gaps between sections. Fluid values reduce the number of breakpoints a stylesheet needs, and they remove the abrupt jumps that appear when a size changes at a single width. For choices about size, spacing and line length, see the guide to web typography.
Designing and presenting for several widths
Working responsively means drawing more than one screen. Most teams sketch at least a narrow layout and a wide layout, then check the widths in between in the browser, since a static drawing cannot show every state. A design file is a starting point and the browser is where the layout is really tested.
Presentation matters too. A narrow design shown inside a desktop-sized window misleads clients about how it will look. Showing small-screen layouts in an appropriately sized frame is one of the uses of browser mockup templates, provided the design inside is genuinely built for a narrow viewport and not a shrunken desktop page.
Common responsive mistakes
- Missing viewport declaration. The page renders at a legacy width and everything looks tiny.
- Breakpoints for devices. Device lists go out of date, while content-driven widths stay correct.
- Hidden content. Removing information on small screens often removes what mobile visitors came for. Reorder and condense it instead.
- Fixed-width media. Images, embeds and tables wider than the screen cause sideways scrolling.
- Locked zoom. Disabling pinch zoom blocks readers who need larger text.
- Touch-unfriendly controls. Small links packed close together are hard to hit with a finger, even if they look neat on a large monitor.
Frequently asked questions
What is the difference between responsive and adaptive design?
A responsive layout flexes continuously and changes at breakpoints where the content needs it. An adaptive approach serves a few fixed layouts for chosen widths. Most current sites combine fluid sizing with a small number of content-driven breakpoints.
Is mobile first required?
No. It is an approach that begins with a simple single-column layout and adds columns as space allows, which MDN describes as a common pattern. It keeps the narrowest layout simple and makes extra complexity opt-in.
Do all pages need the viewport meta tag?
Any page meant to be viewed on phones needs it. Without it, mobile browsers render at a legacy desktop width and shrink the result.
Should breakpoints match popular phone sizes?
No. Device sizes change constantly. Set breakpoints where the content breaks, using relative units.
