Check any website at phone, tablet and desktop widths

Most responsive checkers show one device at a time and make you click through them. This one lays the widths out together, so the phone, the tablet and the laptop view of the same page sit next to each other and you can see where the layout changes.

• 375 pixels is the iPhone width most sites are built around. It is where headlines wrap, menus collapse and buttons start touching.
• 768 pixels is an iPad in portrait, and the width most layouts handle worst because it is neither phone nor desktop.
• 1280 pixels is a laptop. It is what the designer saw, so it is usually fine, and it is the baseline for the other two.
• Add a width. 430 for the larger phones, 1024 for a tablet on its side, 1440 for a big monitor, or type any number.

Each frame is the real page at that exact width, not a screenshot, so you can scroll it, open the menu and click through. The address bar carries the URL, so you can send the check to a client or a colleague as a link.

• Some sites refuse to load inside another page. Banks, the big platforms and many sites running a security plugin send a header that tells the browser not to embed them. We check for that header first and tell you, rather than leaving you looking at a blank box.
• A frame is not a phone. Pixel density, system fonts, Safari's address bar and real touch are all different on the device. Check the layout here, then check the launch on a real phone.
• Hover is a mouse. Menus that open on hover will behave as they do on a desktop.
• A staging site behind a password loads only if your browser is already signed in to it.
• Nothing is proxied or stored. The page is loaded straight from its own server into your browser. We never see it.

• A headline that wraps to four lines at 375.
• A horizontal scrollbar at phone width, almost always from a fixed-width image, table or embed.
• A menu at 768 that is neither the desktop bar nor the mobile button.
• Buttons and links closer together than a thumb.
• Form fields with text smaller than 16 pixels, which makes iOS zoom in when tapped.
• A five-column footer squeezed to one column of fifty links.
• Hero text sitting over the wrong part of the image once the image is cropped for a tall screen.

A screenshot of the phone view tells the developer something is wrong. It does not tell them which element, on which page, at which width, and by the time the fix is deployed the screenshot is out of date.

A HopBack review loads the same page at the same three widths, and the client clicks the thing they mean. The pin records the element, the page and the width it was placed at, so "the menu is broken" arrives as "the menu, on the pricing page, at 375 pixels". When the fix goes live the pins are still on their elements. Sites that block embedding load in a HopBack review too, because the review fetches the page rather than framing it.