Responsive Tester Add To Chrome

A responsive website testing checklist

Fact-checked

Review the widths where your layout changes, the content that stretches it, and the interactions people need to finish.

A page can look right in three device presets and still break between them. Use this checklist after a layout change or before a release. Keep the test page, viewport width, and UI state with each issue so the next person can reproduce it.

Choose widths around the layout

  • Open a narrow phone width, a tablet width, and a desktop width that matter to your audience.
  • Add the exact widths where navigation, columns, or other major components change.
  • Check immediately below, at, and above those thresholds.
  • Resize slowly between the presets to catch awkward intermediate layouts.
  • Try a short viewport as well as a narrow one, especially for dialogs and sticky controls.

For example, a layout with a 768px breakpoint deserves a pass at 767px, 768px, and 769px. That is a useful boundary check, not a reason to treat 768px as the correct breakpoint for every site. Choose thresholds around the content your design must fit.

Responsive Tester's custom viewports and workspaces let you save a repeatable set. Site Breakpoints can also build a set from supported width queries in accessible stylesheets.

Check content and horizontal overflow

  • Scan the full page for accidental sideways scrolling.
  • Try long headings, product names, URLs, and translated labels.
  • Check empty lists, one-item lists, and dense content.
  • Make sure images and video fit their containers without an unintended crop or distortion.
  • Check tables and code blocks: intentional scrolling should stay inside their own region.

If a flex or grid child refuses to shrink, inspect its minimum size. Depending on the layout, min-width: 0 may allow it to shrink, but the content still needs a sensible wrapping or scrolling strategy. MDN explains the automatic minimum size rules.

Avoid hiding overflow on the whole page as your first fix. That can conceal the symptom while leaving content cut off. Responsive Tester's overflow warning helps identify which viewport needs a closer look.

  • Open and close the mobile menu at narrow and intermediate widths.
  • Resize with the menu open and check whether focus and scrolling still make sense.
  • Open dropdowns near screen edges and dialogs with long content.
  • Scroll far enough to activate sticky headers, floating buttons, or banners.
  • Check that the last link or action remains reachable.

Compare the same UI state across viewports. A closed menu on desktop and an open menu on mobile can be intentional; a button stranded outside the visible area is not. Use scroll and interaction sync where it helps, then check controls individually when the mobile and desktop interfaces differ.

Test forms and keyboard navigation

  • Move through the page with the keyboard and check that focus stays visible.
  • Try form labels, help text, validation messages, and long entered values.
  • Open selects, date pickers, and other controls that have their own popovers.
  • Test error and success states, not just an empty form.
  • On a real phone, open the software keyboard and confirm the active field and next action remain reachable.

For a checkout or another action with real consequences, use your application's test environment and test data. The layout review should include the complete flow, including the state after submission.

Check text size and zoom

  • Increase browser zoom and look for clipped headings, overlapping controls, and missing content.
  • Check larger text settings where available.
  • Look at long paragraphs as well as short interface labels.
  • Confirm that important actions remain understandable when labels wrap.

Scaling Responsive Tester's canvas makes the previews easier to arrange. It is different from zooming the page itself, so open the page outside Responsive Tester and do a separate browser-zoom check. Treat these checks as part of a wider accessibility review, not proof that the page passes an accessibility standard.

Finish in real browsers and devices

Side-by-side previews are useful for finding layout problems quickly. They do not turn Chrome into Safari or Firefox. Check important pages in the browser engines your users rely on, and finish key mobile flows on a physical device.

Chrome itself describes Device Mode as an approximation. Real-device checks are particularly useful for software keyboards, touch behavior, browser controls that resize the visible area, and device performance.

Record the issue and retest the fix

A useful responsive bug report contains:

  • The page URL or route and the browser used.
  • The viewport width and height.
  • The steps and UI state needed to show the problem.
  • A screenshot, the expected result, and what actually happened.

After fixing the source, reload and retest the failing width plus the neighboring widths. If you experimented with CSS in the browser, make sure the fix survives a clean reload with Responsive Tester disabled or its saved changes discarded. The guide to editing CSS across breakpoints covers that workflow.

For a tool to run these checks, compare responsive testing tools or get started with Responsive Tester.