The best responsive design testing Chrome extensions
Three different approaches — resize the real window, show every size at once, or read the breakpoints the page declares. They catch different bugs, and knowing which is which saves you an afternoon.
Responsive Viewer if you want every breakpoint side by side on one canvas. Window Resizer if you want a real browser window at an exact size, with a keyboard shortcut. Design Toolkit if you want the side-by-side screens inside the toolkit that also inspects, measures and copies the design, and a copied section keeps the page's own breakpoints. And DevTools device mode is still free, built in, and enough for most of it.
Three approaches, three kinds of bug
Emulated viewports — DevTools device mode, Responsive Viewer — render the page in a frame of a chosen size. Fast, and they find layout breaks. They cannot reproduce anything about the device itself.
Real window resizing — Window Resizer — changes the actual browser window. Slower and capped by your monitor, but the page gets a genuine viewport, so nothing behaves differently because it detected emulation.
Reading the breakpoints — an inspector — skips the resizing. Instead of hunting for the width where something changes, you read the @media and @container rules that apply to the element you are on. This is the one that finds the breakpoint you did not know existed.
| Tool | Approach | All sizes at once | Real viewport | Shows the breakpoints | Price |
|---|---|---|---|---|---|
| Responsive Viewer | Emulated frames | Yes | No | No | Free |
| Window Resizer | Real window | No | Yes | No | Free |
| Design Toolkit | Emulated frames | Yes | No | In a copied section | Trial, then one payment |
| DevTools device mode | Emulated frame | No | No | Partly | Free, built in |
| Viewport Resizer | Emulated frame | No | No | No | Free |
1. Responsive Viewer
Responsive Viewer
Puts a row of device frames on one canvas and loads your page into all of them at once, with the scrolling synced. Change something and every size shows you the result together, which is a different kind of feedback from stepping through widths one at a time — you see which breakpoint is the odd one out rather than trying to remember what the last one looked like.
- Every breakpoint visible simultaneously, scrolling in sync
- Custom screen sizes alongside the device presets
- Screenshots of all frames in one go
Weak spot: rendering a dozen copies of a heavy page is slow, and because the frames are still a desktop browser, anything gated on the user agent behaves as desktop.
2. Window Resizer
Window Resizer
Snaps the browser window itself to a resolution you pick, from a list you can edit, with keyboard shortcuts for the sizes you use constantly. Since it is the real window, the page sees a real viewport — no emulation layer to behave differently, and features that check window size get the truth.
- Your own preset list, reorderable, with shortcuts
- A real viewport, so nothing detects emulation
- Optionally accounts for the window chrome so the viewport is exactly the size you asked for
Weak spot: one size at a time, and you cannot test a width larger than your screen.
3. Design Toolkit
Design Toolkit Ours
Responsive mode (press R) puts several screens next to each other: add a device from a searchable list of phones, tablets and desktops or type a custom size, rotate each screen on its own, zoom out to fit them all and scroll them together. Copy a section as code and the page's own @media and @container rules come with it, so the widths at which the layout changes are written out for you.
- Several screens side by side, from a searchable device list or a custom size
- Rotate, remove (it asks first), zoom to fit, and sync scroll across every screen
- A copied section keeps the page's
@mediaand@containerrules - The rest of the toolkit in the same place — spacing, type, color, contrast
Weak spot: the screens are emulated frames inside one browser, so they cannot reproduce touch behaviour, the mobile address bar, real fonts or a real network. For a real window at an exact size, pair it with Window Resizer. And it is paid after the trial.
4. DevTools device mode
Chrome DevTools
Free, already there, and more thorough than most people use it. Beyond the size presets it throttles the network and CPU, spoofs the user agent, emulates touch, and shows the media query bars across the top of the ruler — click one and it jumps to that width.
- Media query bars: the breakpoints, clickable, above the page
- Network and CPU throttling to approximate a mid-range phone
- User agent spoofing, so server-side mobile detection triggers
- Device pixel ratio, so you can test which image the
srcsetpicks
Weak spot: one viewport at a time, and comparing two sizes means flipping back and forth.
5. Viewport Resizer
Viewport Resizer
A toolbar of sizes injected over the page. Click a size, the page reflows into it. The appeal is that it stays out of the way — no panel, no separate window, and it can be triggered on a client's machine without explaining DevTools to anyone.
- Very low friction for a quick check
- Editable size list
- Good for demoing responsiveness to someone else
Weak spot: it injects into the page, so on complex apps it occasionally fights the site's own layout.
What none of them catch
Every tool here emulates a size. Three classes of bug survive that, and they are the ones that reach production:
- The changing viewport height. On a real phone the address bar hides as you scroll, so
100vhis taller than the visible area at first and shorter later. Usedvhand check on hardware. - Sticky hover. With no pointer to move away, a tapped element can keep its hover state. Wrap hover styles in
@media (hover: hover). - Different fonts. A face installed on your machine but not on the phone falls back to something with different metrics, and the layout that fit breaks by a line.
Read the breakpoints instead of hunting for them
Hover an element for the media and container queries that apply to it, and what each one changes. Free for 7 days.
Add to ChromeNo accountRuns locally14-day refund
Common questions
Is DevTools device mode enough?
For layout, almost always. What it cannot reproduce is the device: touch behaviour, the address bar changing viewport height, real network conditions, and font rendering. Find the layout breaks there, confirm the important ones on hardware.
What breakpoints should I test?
The ones your CSS declares, not a list of device names. Read your media queries, test a few pixels either side of each, and check the narrowest width you support — 320px is still the usual floor.
Why does it look right in device mode but broken on a real phone?
Usually the viewport height changing as the address bar hides, hover styles sticking after a tap, or a font that exists on your desktop and not on the phone.
How do I find the breakpoints on a site I did not build?
Read its media queries. An inspector that reports the breakpoints affecting the element you are on gives them directly; otherwise open the stylesheet in the Sources panel and search for @media.