Building better software, one stack at a time.

Web Development

Common Mistakes in Responsive Web Design (and How to Fix Them)

Common Mistakes in Responsive Web Design (and How to Fix Them)

Responsive design has been standard practice for well over a decade, yet the same handful of mistakes still turn up in audits of otherwise well-built sites. They rarely break a layout outright. Instead they show up as a horizontal scrollbar on one phone, a button that's fiddly to tap, or an image that shoves the page around as it loads.

Most of these problems share a root cause: designing for the screen in front of you rather than the range of screens your visitors actually use. The good news is that each one has a fix you can usually apply without redesigning anything. Here's what to check, roughly in the order you'll get the most value from it.

Start with the viewport meta tag

If the tag is missing, a phone browser assumes your page was built for a desktop and lays it out in a viewport around 980 CSS pixels wide, then zooms out to fit. Text looks tiny, tap targets become guesses, and everything you did with media queries is fighting a battle it can't win.

The fix is one line in the <head>:

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

While you're there, check that you haven't added maximum-scale=1 or user-scalable=no. Both block pinch-zoom, which is a genuine accessibility problem and a poor trade for whatever it was meant to solve. A common reason people add them is to stop iOS zooming in when a form field is focused. The proper fix is simpler: give inputs a font size of at least 16px so the browser has no reason to zoom.

Pick breakpoints from the content, not a device list

A lot of stylesheets still carry breakpoints lifted from hardware that nobody owns any more: 320, 375, 414, 768, 1024. The result is a layout that snaps awkwardly at 768 while looking cramped at 700 and 800.

Work in the opposite direction. Start with the narrowest layout, then widen the browser window slowly until something looks strained — a headline wrapping badly, cards squashing, a sidebar crowding the text. That width is your breakpoint. Set it with min-width media queries so styles layer on top of each other rather than resetting.

You'll often need fewer breakpoints than you expect, because modern CSS does much of the work for you:

  • Grid with auto-fit: repeat(auto-fit, minmax(260px, 1fr)) reflows card layouts without a single media query.
  • Flex wrap: lets a row of items drop to a new line when there's no room, which is often all you wanted.
  • Fluid type and spacing: clamp() scales a value between a floor and a ceiling, smoothing the jumps between breakpoints.

Test at a handful of widths — 360, 390, 768, 1024, 1280 — but treat them as samples, not targets. The layout should be reasonable at every width in between.

Stop images fighting their containers

Images cause more responsive breakage than any other element, usually for one of three reasons.

They overflow their box

A fixed pixel width from a design mockup will happily push a narrow column wider than the screen. Set max-width: 100% and height: auto on images globally, then use aspect-ratio when you need a consistent shape for thumbnails and banners.

They arrive at the wrong size

Serving a 2400px-wide hero to a phone wastes bandwidth and delays the first meaningful paint. Use srcset with a sizes attribute so the browser can choose an appropriate file, and switch to WebP or AVIF with a sensible fallback. If an image is cropped very differently on mobile, that's a job for <picture> with a media query rather than a straight resize.

They shift the page as they load

Without dimensions, the browser reserves no space, so content jumps once the file arrives. Add width and height attributes to every <img> — the browser uses the ratio to reserve space, and CSS still controls the rendered size. Add loading="lazy" to images below the fold, but leave your hero image eager so it isn't delayed.

Make touch targets genuinely tappable

A thumb is not a mouse cursor. Guidelines from the major platform vendors point to roughly 44 to 48 CSS pixels as a comfortable minimum touch target, and that's a good working rule regardless of which device someone is holding.

Failing this is easy to do accidentally: icon-only close buttons sized to the icon, social links packed side by side, checkbox labels that are just text next to a small square. The fix is padding rather than bigger icons, and making the whole label clickable rather than only the control.

Two related traps are worth checking at the same time:

  1. Hover-only interactions. Dropdown menus that open on hover have no equivalent on a touchscreen. Make sure a tap or a focus event opens them too, and that they close cleanly.
  2. Disappearing focus styles. Removing the outline because it looks untidy leaves keyboard users with no idea where they are. Replace it with a visible custom focus style instead.

Watch your text size and line length

Body copy below 16px is hard work on a phone, and full-width paragraphs on a large monitor are worse — the eye loses its place on the return sweep. Aim for roughly 50 to 75 characters per line, which you can enforce neatly with max-width: 65ch on your text container. Fluid type with clamp() is useful for headings, but keep the lower bound at a size you'd be happy to read yourself, and check contrast against the background while you're at it.

Test on something you can hold

Dragging the browser window in and out is a quick sanity check, not a test. It won't show you how the page behaves when a virtual keyboard covers half the screen, when the browser chrome collapses as you scroll, or when a notch eats into the top edge.

Two habits close most of that gap. First, use dvh or svh units for full-height hero sections rather than 100vh, so the section doesn't overflow behind the address bar. Second, keep one real phone and one tablet within reach and load the staging site on them before every release. It takes two minutes and catches things no emulator will.

A 30-minute pass you can run today

Open your site on a phone and work through this in order. Confirm the viewport tag is present and unblocked. Squeeze the browser from 320px upwards and note every point where the layout looks awkward, then set breakpoints there instead of at device widths. Add max-width: 100% and explicit dimensions to your images. Walk through the main pages tapping every button and link in the navigation, and widen anything that feels like a guess. Finally, set a sensible max-width on body text.

None of it requires a rewrite, and the improvements compound. Fix these first and the more ambitious work — performance, accessibility, a design refresh — gets much easier to judge, because you're no longer looking at a layout that shifts under your feet.

Photo: Negative Space / Pexels

Related Posts

A Beginner's Guide to UK GDPR for Web Developers: Cookies, Consent and Data Requests

Web Development

A Beginner's Guide to UK GDPR for Web Developers: Cookies, Consent and Data Requests

Practical UK GDPR guidance for small websites: how cookie consent really works, what to record, and how to answer...

How to Prepare Your E-commerce Site for the UK Christmas Shopping Rush

Web Development

How to Prepare Your E-commerce Site for the UK Christmas Shopping Rush

A practical guide to load testing, caching, payment limits, stock messaging and calm launch freezes so your shop...