Viewport Meta Tag Checker

What the meta viewport tag does, and why blocking zoom is the costly mistake.

One line in the head decides how wide a page is on a phone and whether a visitor may enlarge it. Here is what each part of it does, the errors that turn up on real sites, and where Google's old mobile test went.

What the tag does

A phone's screen is a few hundred CSS pixels wide, and most of the web was built for screens three or four times wider. When mobile browsers arrived, they solved that by pretending: with no instruction from the page, they lay it out at a desktop width and shrink the result to fit the screen. When we loaded a page with no viewport tag in Chrome's mobile emulation at a 390-pixel phone width, the page was laid out 980 pixels wide. Text arrives at a third of its intended size, and the visitor has to pinch and pan to read anything.

The viewport meta tag is how a page opts out of that. It sits in the <head>, written as <meta name="viewport" content="...">, and tells the browser how wide the layout should be and how zoomed in it should start. A responsive stylesheet depends on it: media queries measure the layout width, so on a page without the tag they see 980 pixels and serve the desktop layout to every phone. That is why the tag is the first thing to check when a page with a perfectly good mobile design still looks tiny on a phone.

The standard value

Almost every page wants the same line, the one MDN and web.dev both give:

<meta name="viewport" content="width=device-width, initial-scale=1">

width=device-width sets the layout width to the screen's width in CSS pixels, so a 390-pixel phone gets a 390-pixel layout and your media queries fire. initial-scale=1 says to open the page at 100 percent, neither zoomed in nor out. Nothing else is needed, and in particular nothing that limits zoom. Anything added to that line should have a reason you can name.

Each property, and what this checker does with it

The content value is a comma-separated list of name and value pairs. These are the ones that turn up in practice:

One detail worth knowing: in the same Chrome emulation, a tag carrying only initial-scale=1, with no width at all, still produced a 390-pixel layout. The browser derived the width from the scale. That is why this checker fails a fixed number but marks a missing width for review when initial-scale is there, and why the standard line sets both anyway: it states the intent in the way every reference and audit tool expects to read it.

Blocking zoom is an accessibility problem

The two properties that limit zoom, user-scalable=no and a low maximum-scale, are the ones that cause real harm. A visitor with low vision, or anyone reading a phone in sunlight, enlarges text by pinching. Take that away and small print stays small.

The Web Content Accessibility Guidelines cover this under Success Criterion 1.4.4, Resize Text, at Level AA: "Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality." The W3C's own test rule for that criterion, "Meta viewport allows for zoom", fails a tag with user-scalable=no or a maximum-scale below 2. The open-source axe-core engine applies the same two tests and maps them to 1.4.4. This checker is slightly more lenient on the second: it counts zoom as blocked at a maximum-scale of 1 or less, where the visitor cannot enlarge the page at all, and marks anything between 1 and 2 for review rather than passing it silently.

Be precise about the effect. The W3C rule itself notes that most modern mobile browsers either ignore the zoom limit by default or offer an accessibility setting that overrides it, so on many phones a visitor can still pinch. The tag is still a failure in every accessibility audit that tests it, and it is still the page telling the browser to stop people enlarging the text. For a firm whose pages carry disclosures, fee tables or risk statements in small type, that is the wrong instruction to be giving. Developer tools such as webhint and axe-core already flag it; it is less often explained to the people who own the words in that small print.

Common errors

• No tag at all. Older themes, hand-built landing pages and some email-to-web exports ship without one. The page renders at desktop width on every phone.
• A fixed width. width=1024 or width=980, left over from a site designed before responsive layouts. In our emulation test width=1024 produced a 1024-pixel layout on a 390-pixel screen.
• Two viewport tags. Usually a theme's tag plus one added by a plugin or a tag manager. They can disagree. When we loaded a page with a device-width tag followed by a width=1200 tag, Chrome applied the second and laid the page out 1200 pixels wide; reversed, it applied the device-width one. This checker reads the first tag's value, so with two it may be reporting the one a phone ignores. It fails the page on the count alone for that reason. Keep exactly one.
• user-scalable=no copied from an app template. Web-app starter kits set it to make a site feel like a native app. On a content site it does nothing useful and blocks zoom.
• maximum-scale=1 to stop form zoom. iPhones zoom in when a visitor taps a form field whose text is under 16 pixels, and capping the scale is a common way to suppress that. The fix that does not block zoom is a 16-pixel font size on inputs.
• Semicolons instead of commas. width=device-width; initial-scale=1 is common. Chrome still applied it in our test but logged an error, "';' is not a valid key-value pair separator. Please use ',' instead." This checker accepts either separator, so it will not flag it; use commas.
• initial-scale other than 1. A value like 0.5 opens the page zoomed out, which reproduces the tiny-text problem the tag exists to solve.
• A spelling slip. width=device width with a space, or device_width, is not recognised, so the page falls back to whatever the browser decides.

What Lighthouse checks, and where the Mobile-Friendly Test went

Google retired its Mobile-Friendly Test, the test's API and the Search Console Mobile Usability report on 1 December 2023, and pointed site owners to Lighthouse instead. Many pages that rank for a mobile friendly test still link to a tool that no longer exists. Lighthouse's viewport audit, as web.dev documents it, looks for a viewport meta tag in the head, a content attribute on it, and width= inside that attribute. It is a presence check. The zoom question is asked in Lighthouse's accessibility section and in engines like axe-core, not in the viewport audit itself.

This checker is not a whole-page mobile test either, and it does not claim to be. It reads one tag, precisely. Text size, tap-target spacing, content wider than the screen and layout shifts all need the page rendered on a phone-sized screen, which Lighthouse and Chrome DevTools' device mode do. Use this to confirm the tag is right, and a render to confirm the layout that depends on it.

viewport-fit=cover and notched phones

Phones with a notch or rounded corners draw a page inside a safe rectangle by default, leaving bands at the edges. Adding viewport-fit=cover lets the page fill the whole screen, and in exchange the stylesheet has to keep text and buttons clear of the notch using the env(safe-area-inset-top) family of CSS values. It is a design choice for full-bleed layouts, not a fix, and a site that adds it without the padding rules can put its navigation under the camera cut-out. This checker shows it in the tag's value and leaves it ungraded for that reason.

What a good tag looks like

One tag, in the head, near the top: width=device-width, initial-scale=1, separated by a comma, with no user-scalable and no maximum-scale. Add viewport-fit=cover only if the design has been built for it. Then check again after any theme update, plugin install or tag-manager change, because those are how a second tag arrives.