The viewport meta tag: the one correct value, and why never to disable zoom

The viewport meta tag is one line in the <head> that tells a phone to lay the page out at the screen's own width instead of at a desktop width, and the only value most sites need is <meta name="viewport" content="width=device-width, initial-scale=1">. Without it, mobile browsers render the page about 980 px wide and shrink it until the text is unreadable. Adding user-scalable=no or maximum-scale=1 to it is the most common mistake: it stops people from pinch-zooming on Android. This guide explains each setting, the real fix for the problem those words are usually added for, and how to test the result. It is part of our guide to making a website mobile friendly.

Quick answer

• The correct tag, once, in <head>: <meta name="viewport" content="width=device-width, initial-scale=1">.
• Remove user-scalable=no, user-scalable=0 and any maximum-scale below 5. They block zoom and fix nothing.
• iOS zooming into a form field when tapped? Give inputs font-size: 16px. That is the fix, not the viewport tag.
• viewport-fit=cover and interactive-widget are the only extras with a real job; add them only if you need them.
• The page must still work at 200 % text size (WCAG 1.4.4) and at 320 CSS px wide (WCAG 1.4.10) without sideways scrolling.
• Test with the mobile-friendly test and the accessibility checker.

What is the viewport?

The viewport is the area of the browser window that shows the page. On a phone there are two of them:

• The layout viewport is the width the browser uses to lay out the page and to evaluate CSS media queries. Without a viewport tag, mobile browsers assume about 980 CSS px, the width of a typical desktop page in 2007, so that sites built only for desktop still fit.
• The visual viewport is the part of that layout the visitor actually sees. When they pinch-zoom, the visual viewport shrinks while the layout stays the same.

The viewport meta tag, introduced by Apple for the first iPhone and now described in the CSS Viewport specification, tells the browser to set the layout viewport to the device's width. From then on, a phone that is 390 CSS px wide lays the page out at 390 px, and your media queries and breakpoints take effect. Without the tag, a responsive stylesheet does nothing on phones, because every phone pretends to be a 980 px screen.

The correct viewport meta tag, setting by setting

<!-- In <head>, before any stylesheet -->
<meta name="viewport" content="width=device-width, initial-scale=1">

Separate settings with commas. Put the tag once, in the <head>: in a page with two tags, the later one generally wins, so a plugin's tag can silently override the theme's.

Why never to disable pinch-zoom

Pinch-zoom is how people with low vision, anyone reading without their glasses and anyone in bright sunlight cope with small text. It works on every page by default. Two words in the viewport tag take it away:

• Chrome on Android and most Android browsers honour user-scalable=no and a low maximum-scale, unless the visitor has found the "force enable zoom" switch in the accessibility settings.
• Apps' built-in browsers (a link opened from a social or messaging app) generally honour it too.
• Safari on iOS has ignored both for pinch gestures since iOS 10, so testing on an iPhone hides the problem.

WCAG 2.2 has two level AA criteria here. 1.4.4 Resize Text says text must be resizable to 200 % without loss of content or function, which a zoom lock fails outright. 1.4.10 Reflow says content must fit 320 CSS px without scrolling in two directions, which is what a 1280 px window becomes at 400 % zoom.

The real fix for iOS input zoom

Most maximum-scale=1 tags exist because Safari on iOS zooms in when a visitor taps a form field whose text is smaller than 16 px, and does not always zoom back out. The correct answer is to make the field's text 16 px:

/* Safari stops zooming into fields once their text is 16px or larger */
input, select, textarea {
  font-size: 16px;
}

That also makes the fields easier to read. Our guide to responsive font size covers minimum sizes for body text and fluid type. A map or canvas game that must pan instead of zoom needs touch-action: none on that one element, not a zoom lock on the whole page.

How getReport checks the viewport tag

The mobile-friendly test loads the page once in Chromium and resizes it to 360, 414, 768, 1024 and 1440 px. At each width it takes a screenshot and names anything wider than the screen, counts text under 12 px and tap targets under 24 × 24 px. The full report adds three findings:

This comes from the SEO module, because a missing tag is a mobile-first indexing problem before it is an accessibility one: Google's smartphone crawler sees the same shrunken desktop layout as a visitor. The mobile viewport fix page has the short version.

The report renders the page in Chromium and reads the viewport tag as the browser saw it, after any script that rewrites it, and runs axe-core. The finding fails when the content contains user-scalable=no (or =0) or a maximum-scale below 2, the same threshold as axe's meta-viewport rule. The evidence line quotes the exact content:

A page with no viewport tag passes this one (nothing blocks zoom) and fails the SEO finding instead.

axe rates meta-viewport as a moderate issue, so a blocking tag also appears in this group. A maximum-scale between 2 and 5 passes the zoom finding but trips axe's best-practice rule meta-viewport-large, listed with the minor issues; that is why the fix text asks for 5 or more.

A correct tag with a fixed-width element still scrolls sideways. This finding names the element at the narrowest width where it happens.

Step by step

1. Find the tag

View the page source (Ctrl+U, or Cmd+Option+U on a Mac) and search for name="viewport". There should be exactly one. If the source has none but the report quotes one, a script added it; search the built JavaScript for viewport.

2. Replace it with the correct value

Use the tag above and remove everything else. If an iPhone design draws under the notch, add viewport-fit=cover and pad fixed headers and footers with env(safe-area-inset-top) and env(safe-area-inset-bottom).

3. Test at 200 % and 400 %

• Text size (1.4.4): in Chrome, Settings → Appearance → Customise fonts, set Font size to 32 (200 % of the 16 px default). In Firefox, Settings → Fonts, default size 32. Text in rem or em grows; text in px does not follow this setting.
• Page zoom (1.4.10): Ctrl/Cmd and plus, up to 400 % in a 1280 px window. The page should look like a phone layout: one column, no horizontal scrollbar, nothing cut off, nothing important hidden behind a fixed header.

What usually breaks at 400 %, and the CSS that fixes it:

/* Containers shrink with the viewport instead of forcing a scrollbar */
.container { max-width: 1140px; width: 100%; }

/* Images and embeds never overflow their box */
img, video, iframe { max-width: 100%; height: auto; }

/* Wide tables scroll inside their own box instead of the whole page */
.table-wrap { overflow-x: auto; }

4. Keep text-size-adjust at 100 %

Mobile browsers can inflate text on pages they consider not mobile-optimised. Reset stylesheets set text-size-adjust: 100% so text does not jump when a phone rotates, which is fine. none switches the browser's adjustment off entirely and can block text enlargement, so use 100%:

html { -webkit-text-size-adjust: 100%; text-size-adjust: 100%; }

5. Re-run and check on an Android phone

Run the checks again, then pinch on an Android phone. If it still does not zoom, another tag is being added (step 1) or a script calls preventDefault() on touch events.

Platform notes

WordPress

Where the tag comes from, in order of likelihood:

1. The theme's header.php in classic themes. Change it in a child theme, or the next theme update puts it back.
2. Block themes print the correct tag through wp_head, so a bad tag on a block theme comes from a plugin or a code snippet.
3. Mobile, PWA and menu plugins, and some page builders' "prevent zoom on mobile" options. From the server, grep -rl "user-scalable" wp-content/ names the file.
4. A snippet in functions.php added against iOS input zoom. Replace it with the 16 px rule in Appearance → Customize → Additional CSS.

Shopify

Theme Store themes ship the correct tag in theme.liquid. A blocking one usually arrives through an app's script or an edit to that file; search it for viewport.

Frameworks and static sites

Next.js adds the correct tag by default and lets you change it through its viewport export; Nuxt, Astro and most Hugo themes put it in the layout template. Check the template for a maximum-scale someone added later.

Common mistakes

• Adding maximum-scale=1 to stop iOS zooming into inputs. iOS ignores it for pinch anyway, so it only punishes Android users. Set input text to 16 px.
• Two viewport tags. The theme prints one, a plugin prints another with user-scalable=no. Remove the second.
• Fixed pixel widths on containers. They pass the zoom check and fail reflow at 400 %. Use max-width.
• touch-action: none on body. Added for a swipe gallery, it disables pinch and scroll for the whole page. Scope it to the gallery.
• Testing zoom only on an iPhone. It always works there. Test on Android.

Questions people ask

What does width=device-width, initial-scale=1 mean?

width=device-width makes the page's layout width equal to the screen's width in CSS pixels, so a 390 px wide phone lays the page out at 390 px and your media queries work. initial-scale=1 sets the starting zoom to 100 % and keeps the layout correct when the phone rotates. Together they are the standard viewport value; most sites need nothing else.

What is the difference between the layout viewport and the visual viewport?

The layout viewport is the width the browser uses to lay out the page and evaluate media queries; the visual viewport is the part the visitor currently sees. Pinch-zooming shrinks the visual viewport while the layout stays put. The viewport meta tag sets the layout viewport, and the JavaScript window.visualViewport API reports the visual one, which is useful for toolbars that must stay above the keyboard.

Does the viewport meta tag affect SEO?

Yes, indirectly. Google indexes the mobile version of every page with a smartphone crawler, and without the tag that crawler sees a desktop layout shrunk to a phone, with tiny text and small links. There is no ranking bonus for the tag itself, but a page that is hard to use on phones serves visitors worse, and getReport scores a missing tag as a failed SEO check.

Should I add viewport-fit=cover to the viewport tag?

Only if your design should fill the whole iPhone screen, under the notch and rounded corners. With viewport-fit=cover, the page draws edge to edge, and you must add padding such as env(safe-area-inset-left) so text and buttons are not hidden behind the notch or the home indicator. For most sites the default, which keeps content inside the safe area, is simpler.

How do I stop the page jumping when the phone keyboard opens?

Add interactive-widget=resizes-content to the viewport tag if you want the layout to shrink above the on-screen keyboard, which suits chat windows and forms with a fixed bottom bar. Chromium browsers on Android support it since Chrome 108; Safari ignores it, so also test on an iPhone. For most pages the default behaviour, where the keyboard only shrinks the visual viewport, is fine.