Open Chrome DevTools, press Ctrl+Shift+M, and look at your site at 320 pixels wide. That is the fastest way to test responsive web design, and it costs nothing. The full picture takes a little more: a real phone, one or two free browser tools, and a short checklist you repeat before every launch.
This guide covers each method in the order we use them at Logicode: DevTools for the fast loop, quick viewers like Responsinator for a one-minute check, real devices for the final word, and automated screenshots for sites where a layout break costs money.
How do you check if a website is responsive?
Resize the browser window from full width down to about 320 pixels. A responsive site reflows to fit: no horizontal scrollbar, no content touching the screen edges, no text too small to read. If the page scrolls sideways or columns squash into each other at any width, it fails.
Three failures account for most of the responsive problems we find in audits. Content overflows its container and forces a sideways scroll. Padding collapses on one side, so text touches the screen edge. And tap targets crowd together until a thumb cannot press one without hitting another. All three show up within seconds of resizing a window, which is why the browser itself is the first tool worth learning properly.
Testing responsive design in Chrome DevTools
DevTools is the workhorse. It emulates any screen width, throttles the connection and needs no install. Here is the routine we run on every build:
- Open DevTools with F12, or Cmd+Option+I on a Mac.
- Toggle the device toolbar with Ctrl+Shift+M (Cmd+Shift+M on a Mac).
- Pick a device preset, or type an exact width into the dimensions bar.
- Work through 320, 390, 768, 1024 and 1280 pixels. Those five widths cover a small phone, a current phone, a tablet, a small laptop and a desktop.
- Open the throttling menu and set a slow connection to watch what loads first on a weak signal.
Look for the three failures above at each width, then scroll every page top to bottom. Long headings, wide tables and embedded maps are the usual escape artists.
One limit to respect: DevTools emulates the viewport, not the browser engine. An iPhone runs Safari on WebKit, and Chrome does not reproduce its quirks. Form controls render differently, fixed headers behave differently around the on-screen keyboard, and the safe areas around the notch exist only on the real thing. Treat DevTools as the fast loop, not the sign-off.
Responsinator: the quickest free check
Responsinator loads your live site inside a row of phone and tablet frames, portrait and landscape, on a single page. Paste a URL, press go, scroll down the devices. No account, no install, free.
Two limits are worth knowing. Every frame runs inside your desktop browser, so each device shows the same rendering engine rather than real iOS Safari or Android Chrome. And the device list runs a few generations behind current phones. Use it as a one-minute sanity check and a handy client screenshot, not as proof.
What it does well is answer the question most site owners ask first, which is what does my site look like on a phone, without opening DevTools or learning anything new.
BrowserStack and real-device testing
BrowserStack streams real hardware to your browser: actual iPhones running actual Safari, Android handsets old and new, tablets, different OS versions. You interact with the genuine device, so engine quirks, keyboards and touch behaviour are all real. When a bug appears only on one phone you do not own, this is how you reach it. It is paid, with a limited free trial, and LambdaTest and Sauce Labs sell the same idea.
Honest advice for most business sites: you rarely need it. DevTools plus your own phone plus one borrowed device from the other platform covers the widths and engines your visitors use. Cloud devices earn their fee on custom web apps, checkouts and anything where one broken browser costs real money.
Am I Responsive and other quick viewers
Am I Responsive shows your site in four Apple device frames on one tidy screen. It exists for portfolio screenshots and previews rather than testing: the frames scroll together, there is no interaction and no engine emulation. Fine for a preview image, not a test.
Polypane sits at the other end. It is a paid browser for developers, showing a page at several widths side by side with scrolling and clicks synced between them. If you build sites every week, the saved minutes add up. For an occasional check, DevTools does the same work free.
What replaced the Google mobile-friendly test?
Google retired the standalone Mobile-Friendly Test in December 2023, along with its API. Thousands of people still search for it each month, but the tool is gone. Google now points site owners at two replacements: Lighthouse and Search Console.
Lighthouse lives inside Chrome DevTools and at PageSpeed Insights, and grades performance, accessibility and SEO on a mobile profile. Search Console reports Core Web Vitals from real visitors over time. Neither is a straight swap. The old test answered one narrow question, does the page fit a phone, while these answer a better one: does the page work well on a phone. Slow, unstable pages fail visitors and rankings alike, which is where speed optimisation takes over from layout.
How do you automate responsive testing?
Run browser tests at fixed viewport widths and compare screenshots against a known-good set. Playwright drives the browsers, and a visual regression tool such as BackstopJS or Percy flags any pixel drift. The suite runs on every change, so a layout break surfaces before visitors meet it.
Automation earns its keep on sites where content changes weekly: online stores, booking systems, anything a content team touches. Configure the same five widths you test by hand, screenshot the key templates rather than every page, and review the diffs the way you would review code. On a brochure site updated twice a year, manual checks cost less than maintaining the suite.
Test what emulators miss
Some failures never appear in an emulator. Before sign-off, we check these on hardware:
- Keyboard navigation. Tab through the page at phone and desktop widths. Focus must stay visible and follow a sensible order.
- Tap targets. Buttons and links need roughly 48 by 48 pixels of touch space. Cramped menus fail thumbs, not mouse pointers.
- Contrast in daylight. Pale grey text reads fine on a monitor indoors and disappears on a phone outside.
- Reduced motion. Switch on the system setting and confirm animations settle down.
- A weak connection. Throttle the network and watch the loading order. Heavy images are the usual offender, and image optimisation is the usual fix.
- Landscape. Rotate the phone. Fixed headers eat half the screen sideways, and forms behave differently with the keyboard up.
A responsive testing checklist
Run this before any launch, redesign or big content change:
- No horizontal scroll at any width from 320 pixels up.
- Every section keeps an even left and right gutter. Nothing touches the screen edge.
- Images, tables, videos and embeds stay inside their containers.
- Body text reads without zooming, and form inputs are at least 16 pixels so phones do not zoom on focus.
- Navigation opens, closes and works one-handed on a phone.
- A form completes start to finish on a phone, including its error messages.
- All five widths pass: 320, 390, 768, 1024, 1280.
- Repeat after content changes. A long word in a heading or a wide table breaks a layout months after launch.
The pattern behind nearly every pass and fail is containment. Content respects its container, and the container respects the screen. Responsive layout is one of the foundations in our guide to web design in Ireland, and it is often the first thing we fix in a website redesign. Sites built this way stay responsive as content changes. Sites patched width by width break again with the next blog post. It is one of the clearest marks of a well-built business website.
Frequently asked questions
What screen sizes should you test a website at?
Five widths cover the real spread of devices: 320, 390, 768, 1024 and 1280 pixels. The 320 width matters most. It is the smallest phone still in common use, and a layout surviving 320 rarely breaks anywhere else. Add the most common sizes from your own analytics if they differ.
Is Responsinator accurate?
Accurate for layout, because it loads your real site at genuine device widths. Less reliable for rendering, because every frame runs in your desktop browser engine rather than real iOS Safari or Android Chrome. Confirm anything important on at least one physical phone before calling it done.
Is there a free responsive checker with no signup?
Responsinator works free with no account, and Chrome DevTools ships inside a browser you already have. Between the two you test any width, emulate dozens of devices and throttle the connection without paying for anything. Real-device clouds such as BrowserStack are where costs start.
Does Google rank responsive websites higher?
Google indexes the mobile version of a site first, so a page failing on phones struggles to rank no matter how polished the desktop version looks. Responsive layout is the entry ticket. Speed and stability, measured through Core Web Vitals, decide the placings above it.
Want a site checked at every width before it ships? Responsive testing at all five widths is part of every build we do. See how we build websites or get a free quote.