Responsive Web Design Best Practices for Websites

Responsive web design is an approach to making a website’s layout and content adapt to available space and other device characteristics. Start with flexible content and layout, then change the arrangement when the content needs it. A collection of fixed mockups for particular phone and desktop models is not a responsive strategy.

The practical goal is for people to read, navigate, and use a page across narrow and wide viewports, zoom levels, and interaction modes. This guide covers a content-first workflow, working HTML and CSS, accessibility checks, responsive media, and ways to inspect the result.

1. Start with content and flexible layout

Keep meaningful content in normal document flow so it can reflow as space changes. Fixed page widths often cause horizontal scrolling on narrow screens and excessive empty space on wide ones. Use flexible grids and constrain text measure so lines do not become uncomfortably long.

• Choose a layout based on content relationships and reading order.
• Let columns and components grow or shrink within sensible limits.
• Use maximum widths to keep text and page content from stretching indefinitely.
• Keep the source order useful when columns stack or navigation changes.
• Add a breakpoint when the current arrangement becomes cramped or awkward, not because a device has a particular brand or model.

Flexible grid tracks, relative units, and minimum or maximum values can handle many layouts without media queries. Use a query where the content needs a different arrangement or behavior. MDN’s responsive design guide explains this flexible approach.

2. Set the viewport and build a fluid page

For a responsive page, include a viewport declaration so a mobile browser uses the device width as its layout viewport instead of laying out the page on a wider virtual canvas and scaling it down. The common declaration is:

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

Here is a complete small page you can save as index.html and open in a browser. It uses a fluid grid that wraps based on available space, with one media query for navigation and content spacing. The breakpoint is an example chosen for this layout, not a universal device threshold.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Responsive layout example</title>
  <style>
    * { box-sizing: border-box; }
    body {
      margin: 0;
      color: #17202a;
      font: 1rem/1.55 system-ui, sans-serif;
    }
    .page { width: min(100% - 2rem, 72rem); margin-inline: auto; }
    .site-header, .site-nav, .cards {
      display: flex;
      gap: 1rem;
      align-items: center;
    }
    .site-header { justify-content: space-between; padding-block: 1rem; }
    .site-nav { flex-wrap: wrap; }
    a { color: #0759a5; }
    main { padding-block: 2rem; }
    .cards { align-items: stretch; flex-wrap: wrap; }
    .card {
      flex: 1 1 16rem;
      min-width: 0;
      padding: 1rem;
      border: 1px solid #c8d0d8;
      border-radius: .5rem;
    }
    .card img { display: block; width: 100%; height: auto; }
    h1 { max-width: 18ch; line-height: 1.1; }
    p { max-width: 68ch; }
    @media (max-width: 42rem) {
      .site-header { align-items: flex-start; flex-direction: column; }
      main { padding-block: 1rem; }
    }
  </style>
</head>
<body>
  <header class="site-header page">
    <a href="/">Example site</a>
    <nav class="site-nav" aria-label="Main navigation">
      <a href="#guides">Guides</a>
      <a href="#tools">Tools</a>
      <a href="#about">About</a>
    </nav>
  </header>
  <main class="page">
    <h1>A layout that follows its content</h1>
    <p>The cards below wrap when their container runs out of room. Resize the browser and inspect the page at different zoom levels.</p>
    <section class="cards" aria-label="Resources">
      <article class="card" id="guides"><h2>Guides</h2><p>Practical instructions for common tasks.</p></article>
      <article class="card" id="tools"><h2>Tools</h2><p>Resources to help plan and review a project.</p></article>
      <article class="card" id="about"><h2>About</h2><p>Information about the example site.</p></article>
    </section>
  </main>
</body>
</html>

The flex basis on each card supplies a preferred width, and wrapping lets the browser fit as many cards as the container permits. The min-width: 0 rule helps prevent long content from forcing a flex item wider than its available space. In a production page, also inspect long URLs, unbroken strings, tables, code blocks, and embedded content; each can overflow even when the main layout is fluid.

3. Choose breakpoints from the layout

There is no single breakpoint list that works for every site. Resize continuously and look for the point where navigation wraps badly, columns become too narrow, controls collide, or text measure becomes hard to read. Add a breakpoint around the content failure and change only what needs to change.

Problem observed	Possible response
Several columns become cramped	Reduce the column count or let grid items wrap.
Navigation no longer fits comfortably	Allow wrapping, use a compact navigation pattern, or change spacing.
Text lines become too long	Constrain the content measure with a maximum width.
Controls are crowded at narrow widths	Stack related controls and provide enough room for interaction.
The layout works without a change in arrangement	Keep it fluid; a media query may not be necessary.

Media queries can test viewport dimensions and device features, not just a named device width. They are useful for adjusting columns, navigation, spacing, or interaction affordances. Use relative units for breakpoints where practical, and keep the CSS understandable as the layout grows. See MDN’s media query guide.

4. Make reflow, zoom, and interaction part of the design

Responsive review includes accessibility. WCAG 2.2 Success Criterion 1.4.10, Reflow, requires content to be presentable without loss of information or functionality and without two-dimensional scrolling at a width equivalent to 320 CSS pixels for vertically scrolling content, except where a two-dimensional layout is needed. Check the page at that width and at enlarged text and zoom levels. The WCAG 2.2 Recommendation describes the criterion and its exceptions.

Also verify that enlarged text does not clip, overlap, or hide controls. W3C WAI advises avoiding horizontal scrolling and clipping when text is enlarged by at least 200%, and recommends progressive enhancement so core content and functionality remain available across technologies. See the WAI development tips.

• Keep content and essential actions available in the document flow.
• Test navigation with a keyboard as well as pointer and touch input.
• Check that interactive controls remain usable when space is tight.
• Use media queries for relevant interaction differences where needed.
• Give icons text labels when their meaning would otherwise be unclear.
• Provide alternatives such as captions, transcripts, or descriptions for non-text media when appropriate.

WAI’s design tips discuss how wider layouts may show multiple columns and visible navigation, while narrow layouts or enlarged text may call for a single column and compact navigation. Each responsive presentation remains part of the page being reviewed.

5. Serve images and media for the viewing context

Make images fit their containers and choose image mechanisms based on whether the display needs a different source, resolution, or crop. A responsive image choice in HTML is not the same as a CSS media query: MDN notes that CSS media-query savings apply only to images loaded in CSS. Avoid sending every visitor an unnecessarily large desktop asset by default.

Lazy loading can defer below-the-fold images until they are visible or nearly visible. Use it where it fits the content and loading behavior, and consider which images are immediately important to the page. MDN’s HTML performance guidance covers responsive image selection and lazy loading.

6. Test responsive behavior systematically

1. Resize continuously. Watch when content, controls, columns, and navigation stop working well. Record the layout problem, then choose a breakpoint only if flexible rules do not solve it.
2. Check narrow reflow. Verify the vertically scrolling page at the equivalent of 320 CSS pixels and look for unintended horizontal scrolling. Preserve two-dimensional content only where the WCAG exception applies.
3. Zoom and enlarge text. Look for clipping, overlap, hidden controls, lost content, and horizontal scrolling.
4. Review reading and interaction. Check line lengths, text sizing, navigation, keyboard operation, and touch use at narrow and wide widths.
5. Inspect media. Check that images and embedded media fit their containers, suit the display context, and do not load unnecessarily early.
6. Review the complete experience. Include all responsive variations and, when making a conformance claim, the full page and relevant multi-page task flow.

A screenshot at one viewport can reveal a visual issue, but it cannot establish keyboard accessibility, text enlargement behavior, or whether a control works. Combine visual inspection with browser interaction and accessibility review.

Capture a page at a chosen viewport with Playwright

For repeatable visual inspection, Playwright can set a viewport and save a screenshot. Install it in a Node.js project with npm install --save-dev playwright, then install a browser with npx playwright install chromium. Save this as capture.mjs and run it with node capture.mjs:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage({
  viewport: { width: 320, height: 900 },
  deviceScaleFactor: 1
});

try {
  await page.goto('http://localhost:3000', { waitUntil: 'networkidle' });
  await page.screenshot({ path: 'responsive-320.png', fullPage: true });
} finally {
  await browser.close();
}

Change the viewport width to inspect other sizes, including a wider layout. A full-page image helps inspect the page vertically, but test important viewport-specific interactions in the browser too. Network idle can be unsuitable for pages with continuous requests; in that case, wait for a meaningful selector or use an explicit short delay appropriate to the page.

Capture the same URL through cURL, Python, or Node.js

ScreenshotNeo offers a website screenshot API and MCP server. The API accepts one GET request with a URL and returns an image or PDF. These examples capture a target URL; use your own access key and target site. See the ScreenshotNeo API documentation for request options and response details.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -o responsive-shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
with open("responsive-shot.webp", "wb") as image_file:
    image_file.write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('responsive-shot.webp', Buffer.from(await res.arrayBuffer())));

In Node.js versions that support top-level await, the last example runs in an ES module. Choose the output format and capture settings that fit your review workflow. A screenshot is useful for visual comparison, but viewport capture alone does not test responsive behavior across all widths or prove accessibility conformance.

7. ScreenshotNeo: automate clean visual checks

ScreenshotNeo is a website screenshot API and MCP server for developers, made by Yorker Media. For responsive review, a capture can help you inspect a rendered page at a chosen viewport. Its options include 12 device presets and custom viewports, full-page capture with lazy images loaded, dark mode, retina scale, and image resizing. You can also capture a CSS-selected element, apply custom CSS or JavaScript, wait for a selector, delay, or network idle, and set headers, cookies, or a user agent. The API parameter names used by other screenshot APIs also work, which can make switching easier.

For browser automation, ScreenshotNeo’s MCP server offers take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The API also supports caching with a chosen TTL, signed links for public image tags, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, a usage API, and an OpenAPI specification. Refer to the documentation for setup and option names.

Options that help responsive review

Need	Relevant option
Compare a device-sized viewport	Choose one of 12 device presets or provide a custom viewport; use retina scale where useful.
Review content below the fold	Use full-page capture with lazy images loaded.
Inspect one component	Capture an element by CSS selector, or hide unrelated selectors.
Review alternate presentation	Use dark mode or transparent background as appropriate.
Make a stable capture	Wait for a selector, a delay, or network idle; apply custom CSS or JavaScript if needed.
Review a page that needs authentication or locale context	Provide custom headers, cookies, user agent, timezone, geolocation, or Authorization where appropriate.
Reduce page noise	Block ads, trackers, requests, or resource types. Each step in the consent and widget cleanup can be turned off.

Or skip the browser setup

Make a one-call capture with cURL:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -o responsive-shot.webp

ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and each response says which result occurred in the X-Page-Verdict and X-Billed headers. An MCP server lets AI agents take screenshots. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Every feature is on every plan. See the API docs for options and response headers, then sign up free for 1,000 screenshots a month with no card.

8. Troubleshooting responsive pages and screenshot reviews

Symptom	Likely cause	What to try
The page looks like a scaled-down desktop on a phone	The viewport declaration is missing or incorrect.	Add <meta name="viewport" content="width=device-width, initial-scale=1"> and recheck the layout viewport.
A narrow viewport has horizontal scrolling	Fixed widths, oversized media, long unbroken content, or a component that needs two-dimensional layout.	Find the overflowing element, make it fit or wrap where suitable, and preserve two-dimensional scrolling only for content that needs it.
Text is too wide on a large screen	The content has no measure constraint.	Set a maximum width on text or the reading column.
Cards or controls overlap at one width	The layout change happens too late, or a child cannot shrink.	Resize through the failure point, add a content-driven breakpoint if needed, and inspect minimum widths and long content.
Images overflow or appear blurry	The image is not constrained to its container, or its source is not suited to the display context.	Check sizing and responsive source selection; avoid sending a large desktop asset by default.
A screenshot shows a blank or incomplete page	The page may still be loading, require a different wait condition, or have failed to load.	Wait for a meaningful selector or appropriate delay and inspect the response verdict. ScreenshotNeo’s response identifies page outcomes in its headers.
A screenshot contains a consent banner, popup, or chat widget	The relevant cleanup may be disabled or the platform may not be among the known removals.	Check the capture settings and toggle cleanup steps as needed; the available behavior covers 60+ known consent platforms, newsletter popups, and chat widgets.
The capture request returns an error	The key, URL encoding, destination, or request parameters may be wrong.	Check the access key and encode the target URL as a query parameter; compare the request with the API documentation.

9. Performance, reliability, and cost

Responsive layout rules themselves are not a substitute for sending media appropriate to the display. Avoid unnecessary large assets and use lazy loading for below-the-fold images when it suits the page. CSS media-query loading behavior applies to images loaded in CSS, so do not assume it selects HTML image sources for you.

For reliable visual comparisons, capture the same URL with the same viewport, device scale, wait condition, and relevant page state. Dynamic content, authentication, cookies, or locale can change what a capture shows; configure those inputs when they matter. A timeout or network-idle wait that is too short can capture an incomplete page, while a wait that is too broad can be unsuitable for pages with ongoing requests.

ScreenshotNeo says only clean shots are billed. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing; the response includes X-Page-Verdict and X-Billed headers. Its plans are Free: 1,000 shots per month with no card; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; and Business: $249 for 1,000,000. Yearly billing gives two months free. Every feature is on every plan. These are service plan prices; your own browser automation also has the runtime and infrastructure costs of the environment where you run it.

10. Responsive design review checklist

• Does the layout follow available content width instead of relying on fixed device mockups?
• Does the page reflow at the equivalent of 320 CSS pixels without unintended two-dimensional scrolling?
• Can people zoom or enlarge text without clipping, overlap, or loss of content and controls?
• Are line lengths, text sizes, navigation, and controls usable at narrow and wide widths?
• Do pointer, keyboard, and touch interactions remain available where relevant?
• Do images and media fit, use an appropriate source for the context, and avoid unnecessarily early loading?
• Have you reviewed each responsive variation and the complete page or task flow covered by any conformance claim?
• Have you combined screenshots with actual interaction and accessibility checks?

Frequently asked questions

What is the difference between responsive and adaptive design?

Responsive design describes an approach where layout and content adapt across available space and device characteristics. It can use fluid rules and selective breakpoints; it does not require one fixed design for every device.

Is a mobile-specific site required?

No. A responsive page can serve the same meaningful content in a layout that reflows. The right implementation depends on the product and its content, but separate fixed device mockups are not a requirement of responsive design.

Does passing a screenshot review prove WCAG conformance?

No. Screenshots help review appearance. Conformance review also needs to consider functionality, interaction, and the applicable criteria across the full page and its responsive variations.

Should every image use lazy loading?

No. Lazy loading is useful for images below the fold when it suits their loading behavior. Choose loading behavior based on the image’s place and role on the page.

Sources

• MDN: Responsive design
• MDN: Media queries
• web.dev: Responsive web design basics
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI: Developing for Web Accessibility
• W3C WAI: Designing for Web Accessibility
• MDN: HTML performance features