A responsive site adapts to the screen it is on. That is easy to say and surprisingly hard to get right, because "works on my phone" and "works on every phone" are very different claims. A responsive design checker should tell you not just whether the layout reflows, but whether the result is actually readable and usable at each size.
What responsive really means
Breakpoints are the visible part of responsive design: at some width the navigation collapses into a menu, columns stack, images shrink. But a page can switch layouts on cue and still be broken on a phone. Real responsiveness also means:
- Nothing sticks out. No element is wider than the screen, so the page never scrolls sideways. See content wider than the screen.
- Text stays readable. Body text around 16px, comfortable line height, lines that are not too long or too short.
- Things can be tapped. Buttons and links big enough for a finger, with space between them. See tap targets.
- Nothing overlaps or gets clipped. Headings that wrap to three lines on a narrow phone still fit their box.
- Fixed elements leave room. A sticky header that is fine on a tablet can eat a large part of a small phone screen.
- It survives user settings. Larger system text and dark mode are everyday settings, not edge cases.
It also starts with one line of HTML. Without a viewport meta tag, phones render a desktop-width page and shrink it, and no media query will save you:
<meta name="viewport" content="width=device-width, initial-scale=1">Which widths to test
You cannot test every device, but you can test the widths that real devices actually use. These cover the vast majority of phones and tablets:
| Width (CSS px) | Typical devices |
|---|---|
| 320 | The minimum for WCAG reflow; older small phones and zoomed-in views |
| 360 | Most Samsung Galaxy S phones and many budget Android phones |
| 375 / 390 / 393 | iPhone SE and mini, iPhone 12 to 16, Pixel 5, Xiaomi Redmi Note |
| 412 / 414 | Google Pixel 6 to 9, Galaxy A-series, older iPhone Plus and XR models |
| 430 / 440 | iPhone Plus and Pro Max models |
| 768 | Classic portrait tablet breakpoint |
| 820 | iPad 10th gen and iPad Air in portrait |
| 1024 | iPad Pro 12.9-inch portrait, or small tablets in landscape |
Pay special attention to the narrow end. Designers usually work at 390px or wider, while a large share of Android phones are 360px, and 320px is the width WCAG uses for its reflow requirement. Height matters too: a 667px-tall iPhone SE shows far less on arrival than a 932px Pro Max. Our mobile viewport sizes page lists the exact width, height and pixel ratio of every device in our catalog.
Why real device emulation beats resizing a window
The quickest responsive test is dragging your desktop browser window narrower. It shows you breakpoints, and it is a fine first step. But a narrow desktop window is not a phone:
- Pixel ratio. Phones draw each CSS pixel with 2, 3 or fractional numbers of screen pixels. That changes which responsive images load, how thin borders look and whether text renders crisply.
- User agent. Some sites and plugins serve different markup, scripts or ads to mobile browsers. A resized desktop window gets the desktop version.
- Touch. On a touch device there is no hover, and
(hover: none)and(pointer: coarse)media queries switch on. Menus that open on hover may never open at all. - Browser bars. On a phone, the address bar and toolbar take part of the screen, so the visible area is shorter than the screen itself. That decides whether your main button is visible when the page opens.
- The engine. Every browser on iPhone uses WebKit, Safari's engine. A Chrome window, however narrow, renders with Chromium. See testing on iPhone for the differences.
MobileCheck sets all of these for each device: real CSS viewport, pixel ratio, touch, user agent and browser bars, with WebKit for iPhones and iPads and Chromium for Android.
How the report shows what is broken
A screenshot tells you something looks off. It does not tell you which element is to blame or what to change. For each device, the MobileCheck report shows a full-page screenshot with the exact problem elements outlined on it: the image that pushes the page sideways, the paragraph with 12px text, the two links squeezed together, the heading that overlaps the next line.
Each problem comes with a plain-English explanation of what it is, why it matters for visitors, and how to fix it, linked to a guide with code examples. The page is checked in four scenarios: normal, dark mode, large text at 150%, and with the mobile menu opened, because that is often where responsive layouts quietly fall apart. A score from 0 to 100 lets you see at a glance whether a fix made things better.
Frequently asked questions
Is the responsive checker free?
Yes, completely: no paid plan, no sign-up and no daily limit. Each check can cover any or all of our 51 phones and tablets. Checks run on our server in one shared line (big ones in parts, so nobody waits long behind them), so when it is busy you wait for a few minutes.
Can I enter a custom width?
The check uses real device profiles rather than arbitrary widths, so each test includes the right pixel ratio, user agent and browser bars. The free devices cover the common widths from 360px phones to 820px tablets.
Does it test landscape orientation?
The automated report checks portrait, which is how most people browse. In the phone window of our free extension you can rotate the device to landscape and look around yourself.
Why does my site pass in DevTools but fail here?
DevTools emulation always uses Chromium, while iPhones run WebKit, and our check also accounts for browser bars, large text, dark mode and the opened menu. Problems often appear in one of those scenarios.