Find the width where it breaks.
Mobile View draws device frames over the page you are already on — so your login, your route and your data come with them. Drag a frame’s edge and the layout reflows under your hand until you find the pixel it gives up at.
- Free, no account
- 4 permissions
- No host access at install
- Makes no network requests
iPhone 16393 × 8522 framesFocusRowSyncFidelity393 × 709The readout says 393 × 709, not 393 × 852 — the phone’s own browser bars have been taken off.
Four things the others cannot do.
Every responsive tester shows you a phone-shaped box. These four are what happens when the box is drawn on the live page instead of a copy of it.
Your session comes with it
The frames are drawn over the page you are already on, so they are same-origin — every cookie you already had, Lax and Strict alike, is in every frame. A preview that opens in its own tab is a different site to your browser, and arrives signed out.
Measured before a line was written
It loads sites that block framing
Most serious web apps refuse to be embedded. Mobile View lifts that refusal for the previews only, on the one tab you opened it on, and puts it back the moment you close — so the page you are actually browsing is untouched.
One tab · sub-frames only · removed on close
It subtracts the browser's own bars
A phone's browser takes real height. An iPhone 16 has a 393 × 852 screen and gives a page 393 × 709 — and that 143-pixel gap is where sticky footers go to die. Every other tool hands the page the whole screen and calls it a phone.
393 × 709, not 393 × 852
It tells you what it fakes
A panel names, row by row, which signals are real and which are not — pixel ratio, pointer type, safe-area insets, and the rendering engine. Chrome's own documentation calls device mode a first-order approximation. We print which parts.
7 rows · 4 of them crossed
One of these is a workflow. The other is a habit.
Checking a responsive bug today
- 01Drag the window edge and watch, which is a guess with no number on it
- 02Let go — and the width you were at is gone
- 03Open DevTools, pick a device, reload, pick another
- 04Find the preview signed out, because it is not really your session
- 05Find it will not load at all, because the app refuses to be framed
- 06Give up on localhost entirely
- 07Still not know which pixel it broke at
Checking one with Mobile View
- 01Press Alt+Shift+M — the frames appear over the page you were on
- 02Still signed in, still on the same route, still your data
- 03Up to 5 widths at once, as a row, a grid or a stack
- 04Drag an edge and the layout reflows under your hand
- 05The header names the breakpoint band you are standing in
- 06The readout says what the page actually got, bars subtracted
- 07Works on http://localhost, where the work happens
A device list cannot tell you where it breaks.
Drag a frame's edge and the page reflows under your hand. The frame renames itself Custom, drops its phone bezel — it is not that handset any more — and the header names the CSS breakpoint band you are standing in.
Both framework families are named — 768 is the only width Bootstrap 5 and Tailwind agree on.
Up to 12 of your own, refused with a reason rather than silently clamped.
One page. Every screen size.
Up to 5 frames at once, as a row, a grid or a stack. This is one component rendered three times, not three pictures of it — the layout below really is reflowing.
Burger, one column, full-width call to action
Links appear, cards pair up
Four across, call to action goes inline
32 distinct viewports, and every one hands the page a real height.
One entry per viewport rather than one per handset — the phones that share a size are named on the card. None of them is behind a paywall and none ever will be: a size you cannot reach is a bug you cannot find. Add your own on top, any width you like.
- iPhone12
- Android6
- Foldable3
- Tablet6
- Desktop5
Device names identify screen sizes only. Not affiliated with, endorsed by, or sponsored by Apple, Google, Samsung or any device maker.
A phone's browser takes real height. So we take it off.
Every other responsive tool hands the page the phone's whole screen. A real phone does not — and the difference is exactly where sticky headers and footers fail.
| Device | Screen | Bars | Viewport |
|---|---|---|---|
| iPhone 16 | 393 × 852 | −143 bottom | 393 × 709 |
| iPhone 16 Plus | 430 × 932 | −143 bottom | 430 × 789 |
| Pixel 8 | 412 × 915 | −104 top | 412 × 811 |
| iPad Air | 820 × 1180 | −94 bottom | 820 × 1086 |
| MacBook Air | 1440 × 900 | — | 1440 × 900 |
Which end matters as much as how much. iOS Safari puts its tab bar at the bottom; Chrome for Android puts its toolbar at the top. Same total, other end of the screen — and it decides whether a sticky header or a sticky footer is what breaks. Bars retract as you scroll, so you can turn them off and check the other case too. A desktop size and a size you typed yourself get no bars at all.
Test the experience, not just the size.
The frames are live pages, not screenshots. Scroll them, click them, fill a form, follow a link — and because they are the site you were already on, you are still signed in when you get there. Scroll once and every frame follows.
iPhone 17 Pro402 × 8743 framesFocusRowSyncFidelity402 × 731Replay scrolling, clicks and typing into every frame
It says when it is starting and when it is ready, so a slow site never looks like a broken one. On a fast page you see neither.
Two things it will not pretend about
- Scrolling syncs everywhere. Clicks and typing are matched by position, so on a layout that differs a lot between mobile and desktop some will not replay — you drive that frame directly instead.
- A frame is a fresh visit to the same URL. Your route and your session carry; unsaved form input and in-memory app state do not.
It tells you what it fakes.
A preview that hides its own limits is worth less than one that prints them. So a panel names every signal, says whether it is real, and does not stop at the ones that flatter us.
Send to BugCapture →coming soonThree of these turn green. One never will.
Pixel ratio, pointer type and safe-area insets are fixable, and are on the roadmap below. The engine row is not: nothing running inside Chrome renders with WebKit, so an iOS Safari bug will not appear here — not in this tool, not in the paid ones, not in the browser you are reading this in. A preview that draws a convincing iPhone and stays quiet about that is selling confidence in an untested surface.
4 permissions, and no host access
There are no required host permissions, so “read and change all your data on all websites” — the scariest prompt in the store — is not part of installing this. The one optional permission, keeping the view open across a reload, is asked for from a click, for one site at a time, and dropped again when you restart the browser.
Nothing leaves your browser
No account, no analytics, no telemetry, no server. The extension makes no network requests of its own at all. Privacy policy
Four jobs, one question.
Coming next: it finds the bug for you.
Everything above this line ships today. Everything below it is planned and unbuilt — dates are not promised, and nothing here is a reason to install it now.
Responsive Audit
The frames check themselves. BugCapture's measuring layer already runs inside an arbitrary page and reports type, size and alignment as numbers — running it in every frame and diffing the results across viewports is the part nobody in this category has.
- Horizontal overflow
- Tap targets under 44 px
- Text under 12 px
- Text clipped by its container
- Contrast lost at a breakpoint
Capture
One screenshot of every device at once, full-page rather than fold-height, framed or bare. Recording lands as WebM.
- All frames in one shot
- Full-page
- WebM recording
Accuracy Mode
Three of the Fidelity panel's crossed rows turn green: a real device pixel ratio, a real coarse pointer, real safe-area insets. One profile for the tab, and each frame keeps its own width — so five widths can run at a real 3× at once.
- Real DPR
- Real touch
- Real safe-area insets
Send to BugCapture
The door that is already drawn in the Fidelity panel starts working. A responsive bug becomes a filed BugCapture report — console, network and environment attached, routed to Jira, Linear or GitHub, and carried through to Verified with the verifier's name on it.
- Console and network attached
- Routed to your tracker
- Carried through to Verified
What a responsive audit would look like
Concept — not built- 1The page you are on
- 2Five frames at five widths
- 3Measured in each
- 4Findings, with the width attached
- 5A BugCapture report
- at 393Primary call to action overflows its container by 12 px
- at 768Header and content overlap by 9 px once the nav wraps
- at 360Filter chips are 31 px tall — under the 44 px tap target
Measured, not guessed — and that is the point
Overflow, tap-target size, text size, clipped text and a contrast pair that fails at one width are all things you compute. A number you can reproduce is a number you can put in a bug report without hedging — which is why the audit is arithmetic rather than a model looking at a screenshot and offering an opinion.
There is no language model anywhere in BugCapture, and there is no plan to put one in this path. Where AI does come in is at the end: a filed report is already readable by an AI agent through the BugCapture MCP server, so a responsive finding would arrive in your agent’s context the same way every other bug does.
How the MCP server works todayWebKit rendering is not on this list and never will be. No extension on Chromium reproduces iOS Safari — the engine row in the Fidelity panel stays crossed, and any tool that tells you otherwise is guessing.
The ten things people ask first.
DevTools shows one viewport at a time, replaces your window with it, and resets the size you were at. Mobile View draws up to five frames on top of the page you are already on, so the desktop layout and the mobile one are in front of you together — and it subtracts the phone browser's own toolbars, which DevTools does not, so the height a page gets in a frame here is the height it gets on the handset. Chrome's own documentation calls device mode a first-order approximation; this is one too, and it prints which parts.
Stop guessing which pixel broke it.
Responsive Tester — Mobile View by BugCapture — 32 viewports, a live resize that names the breakpoint, and a panel that tells you what the preview is worth. Free, and it stays that way.
Device names identify screen sizes only. Not affiliated with, endorsed by, or sponsored by Apple, Google, Samsung or any device maker.