Responsive Web Design: A Practical Guide
Responsive design means one site that works at any width, not a separate mobile version. In practice most sites are responsive on paper and broken in specific places — a table that forces horizontal scrolling, a navigation that eats a third of the screen, a form that zooms unpredictably on iOS.
This guide covers how to approach it, where the real failures are, and how to test for them.
Design from the narrow end#
Starting narrow forces the priority decisions. At 320 pixels there is room for one thing at a time, so you have to decide what that thing is; widening a design afterwards is mostly a matter of giving things more room.
Going the other way — designing at 1440 and then removing things — produces mobile layouts that are the desktop with pieces hidden, which is how important content ends up display:none on the device most visitors use.
- Start layouts at 320–360px, the narrowest real devices in common use.
- Never hide content on mobile that a mobile visitor needs; move it or fold it instead.
- Let content decide breakpoints — add one where the layout breaks, not at device names.
- Test with the browser text size at 200%: this is a common accessibility setting and it breaks more layouts than any phone.
Device-named breakpoints age badly. "Tablet" has meant six different widths in ten years; "the point where the card grid gets ugly" does not change.
The elements that actually break#
A handful of components account for most responsive failures, and they are predictable enough to check deliberately.
| Element | Failure | Fix |
|---|---|---|
| Tables | Horizontal scroll on the whole page | Scroll container, or restack as cards with data labels |
| Long words / URLs | Page scrolls sideways | overflow-wrap and min-width:0 on flex and grid children |
| Images | Overflow or layout shift | max-width:100%, explicit width and height attributes |
| Navigation | Takes a third of the screen | Collapse, or move primary items to a bottom bar |
| Forms | iOS zooms in and will not zoom out | Font size at least 16px on inputs |
| Fixed elements | Cover the content they anchor to | Account for them in scroll-padding and body padding |
| Modals | Cannot be dismissed on a small screen | Full-screen on mobile with a visible close control |
Images and media#
Images are usually the largest thing on a page and the most common source of layout shift. Three attributes fix most of it and cost nothing.
- Always set width and height attributes so the browser reserves the space before the file arrives.
- Serve modern formats — WebP or AVIF — with a fallback where you still need one.
- Use srcset and sizes so a phone downloads a phone-sized file, not a 2000px hero.
- Lazy-load images below the fold, but never the largest visible image: that is your LCP element.
- Give the main image fetchpriority="high" so it is not queued behind decorative assets.
- For background images set an aspect ratio so the container does not collapse before load.
Touch, not just width#
Responsive is not only about layout. A narrow viewport usually means a finger rather than a mouse, and finger input has different requirements that width-based media queries alone do not address.
- Touch targets at least 44×44px with spacing between them; adjacent 30px links get mis-tapped constantly.
- Nothing important behind hover — a hover-only menu is unreachable on touch.
- Use pointer:coarse media queries to drop hover effects that stick after a tap.
- Keep primary actions within thumb reach on tall phones; the top-right corner is the hardest place to press one-handed.
- Respect prefers-reduced-motion: parallax and large transitions cause real discomfort for some users.
Frequently asked questions
How many breakpoints do I need?
Usually three to five, and they should come from your content rather than from a device list. Add one where the layout starts to look wrong as you widen the window, not because a particular phone exists. Sites with a dozen breakpoints are almost always compensating for a layout that was not fluid to begin with.
Is a separate mobile site ever right?
Rarely. It means two codebases, two sets of URLs, two deployments and a canonical relationship to maintain, and it usually ends with one of the two quietly falling behind. The cases where it still happens are legacy systems that cannot be made responsive, and even then it is a stopgap rather than a plan.
How do I test responsive design properly?
Browser device emulation catches layout problems but not touch, network or platform behaviour. Test on at least one real low-to-mid range Android and one iPhone, on mobile data rather than office wifi. Then repeat the key pages with browser text size at 200%, which is where most layouts actually fall apart.
What about tables of data on phones?
Two workable options: put the table in a horizontally scrolling container with a visible affordance and a sticky first column, or restack each row as a card where every cell carries its own column label. The scroll container keeps comparison possible; the card stack is easier to read. Choose based on whether visitors compare rows or read one at a time.
responsive web designmobile friendly websitebreakpointsmobile first designresponsive imagestouch targets
