What does the tag <meta name="viewport" content="width=device-width, initial-scale=1"> do, and what happens to a responsive page on a phone if it is omitted?

## Two viewports, which is the point On desktop the window width is the width CSS lays out against, and there is nothing more to know. Mobile browsers split the idea in two: - The **layout viewport** is the rectangle CSS resolves against. It is what percentage widths, `100vw` and media query conditions measure. - The **visual viewport** is the part of that rectangle currently visible on the physical screen, which pinch-zooming changes. When phones arrived, essentially every page on the web was built for a desktop-width window. Rendering those at 360 CSS pixels would have produced unusable columns, so mobile browsers adopted a compromise: default the layout viewport to a **wide fallback — around 980 CSS pixels, engine-dependent** — lay the page out at that width, then scale the finished rendering down so the whole width fits on screen. The result is a miniature but correctly proportioned desktop page you can pinch into. That default is a compatibility measure for pages that predate responsive design. ## What the tag changes ```html <meta name="viewport" content="width=device-width, initial-scale=1"> ``` `width=device-width` sets the layout viewport to the device's own width in CSS pixels — around 360–430 on typical phones — rather than the fallback. `initial-scale=1` sets the starting zoom to 1:1, so no shrink-to-fit is applied. Together they are the declaration "this page is responsive; do not compensate for me". Note that the widths involved are **CSS pixels**, not hardware pixels. A phone with a 1170-pixel-wide panel typically reports around 390 CSS pixels because it renders at a device pixel ratio of 3. You size against CSS pixels; the device pixel ratio is the browser's problem. ## The failure mode without it Everything in the stylesheet still works — it simply works against the wrong number. At a 980px layout viewport, `@media (min-width: 64rem)` is close to matching and `@media (min-width: 48rem)` certainly does, so the phone takes the **desktop branch** of your mobile-first stylesheet, renders a multi-column layout, and then shrinks the whole result to fit a 390px screen. Body text lands somewhere near four or five physical pixels tall. It is the most confusing responsive bug for a beginner precisely because the CSS is correct: the media queries fired exactly as written, against a viewport nobody told them about. ## The values you should not add Two descriptors show up in copy-pasted snippets and should be removed on sight: ```html <!-- do not do this --> <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no"> ``` `user-scalable=no` and a `maximum-scale` of 1 disable pinch zoom. That is an accessibility failure — WCAG 2.1 success criterion 1.4.4 (Resize Text) requires text to be scalable to 200% — and it hurts far more than low-vision users: anyone reading a map, a chart, a scanned document or a small image relies on pinch. Safari on iOS has **ignored `user-scalable=no` since iOS 10**, which tells you how the platform vendors judged the practice, but other engines may still honour it, so removing it is not optional. The usual motivation is suppressing iOS Safari's zoom-on-focus for form inputs. The correct fix is to give those inputs a font size of at least 16px; the browser zooms only when the text would be smaller than that. ## One legitimate extra `viewport-fit=cover` is worth knowing: it lets the page extend under a device's rounded corners and camera cutout, and is what makes the `env(safe-area-inset-*)` values meaningful for padding content back out of harm's way. It is opt-in and unrelated to the core two descriptors. ## The tag's place in the strategy The viewport meta tag is the precondition for everything else in responsive CSS. Mobile-first ordering, content-derived breakpoints and fluid sizing all assume the layout viewport equals the device width. Without the tag they are all still evaluated — against 980 — and every one of them produces the wrong answer. It is one line, it is required, and it is the first thing to check when a page that looks right in a resized desktop window looks tiny on a real phone.