Before releasing a responsive page, why is stepping through a few DevTools device presets not enough verification, and what would you do instead?

## What emulation actually gives you A browser's responsive design mode resizes the viewport, applies a device pixel ratio, and can spoof a user agent string and touch events. That is genuinely useful and covers most layout work. What it does **not** change is the engine: a preset named after an iPhone still renders with your desktop browser's engine, so anything WebKit does differently — form control rendering, some overflow and scrolling behaviour, dynamic toolbar effects on viewport-relative heights — is simply not represented. Emulation is a fast approximation of size, not a substitute for the device. ## Why presets are the wrong sampling strategy Viewport width is continuous. A preset list samples maybe eight points on it. Responsive failures cluster precisely where nobody looked: - A navigation bar that fits on one line at 768 and at 1024, but wraps to two ugly lines between about 800 and 900. - A three-column card grid that leaves a single orphan card on the second row for a 200px-wide stretch. - A heading whose longest word overflows its container only in a narrow band before the next breakpoint takes over. - A fixed-width element — an embed, a table, a code block — that pushes horizontal overflow below some width you never checked. None of these are visible from jumping between presets, and all of them are obvious within seconds of dragging the handle continuously. ## The sweep, and what you are watching for Drag the width from about 320px to the widest window you support, slowly, once per page template. Watch four things: **horizontal overflow** (any scrollbar appearing on the body is a bug, not a size), **clipping or overlap**, **orphans and awkward wrapping**, and **line length** running past comfortable reading at wide widths where the layout has no upper bound. Then stop at the ends: around 320px, and at a very wide window where an unbounded layout stretches paragraphs into unreadable lines. ## The axes that are not width Width is the axis everyone tests, and three others break real pages: **Text size.** Raise the browser's default font size and reload. Anything sized in `px` stays put while `rem`-based sizing and `rem` breakpoints move, and mismatches show up as overlap and clipping. This is a real user setting, not a hypothetical. **Zoom and reflow.** WCAG 2.1 success criterion 1.4.10 requires content to reflow without two-dimensional scrolling down to a width equivalent to 320 CSS pixels — which is what you get at 400% zoom in a 1280px-wide window. Zooming is a different code path from resizing in a couple of respects, so test it directly rather than assuming the narrow-window result transfers. **Height and orientation.** A phone in landscape is short, not just wide. Layouts that assume vertical room — a hero sized to the full viewport height, a sticky header plus a sticky footer — can leave almost nothing between them. Check a short viewport explicitly. ## Content is the other variable Most responsive bugs are content bugs wearing a layout costume. Placeholder text of uniform length hides them. Test with the longest realistic string in each slot: the longest product name, a person with two given names, a category label in the most verbose supported language, a number with the largest expected magnitude. Also test the empty and error states, which frequently have entirely different content lengths and get checked at one width only. ## Where automation helps A width sweep is repetitive, which is a hint. Screenshot comparison at a handful of widths catches regressions cheaply once the layout is stable, and an assertion that `document.documentElement.scrollWidth` never exceeds the viewport width catches the single most common failure — accidental horizontal overflow — at every width you choose to test, without anyone looking at a picture. Keep the automated set small: it is a regression net, and manual sweeping remains how you find things the first time. ## What the interviewer is checking Whether you understand that presets sample a continuum, whether you test axes other than width, and whether you know the boundary of emulation — that the engine underneath is still your desktop one, so the real device is where you confirm rather than where you first look.