Viewport Meta Tag Checker
The viewport meta tag tells a mobile browser what width to treat the page as. It's a single line, but it determines the entire mobile experience: leave it out and the page is assumed to be desktop width and shrunk to fit; configure it wrongly and you get horizontal scrolling; restrict it too far and readers with low vision can't enlarge the page at all. This tool doesn't just look at the tag as a whole, it parses it directive by directive and explains what each one means.
What happens without a viewport tag?
To stay compatible with older desktop sites, mobile browsers assume that a page with no viewport tag is around 980 pixels wide, then shrink it to fit the screen. The visitor sees a zoomed-out desktop page: the text is too small to read and the links are too small to hit with a finger. Google treats such a page as not mobile-friendly, and given that most search traffic is mobile, that's a direct loss of both rankings and conversions.
Why is width=device-width essential?
This directive tells the page to base itself on the real width of the device it's being viewed on. Every CSS media query in a responsive design works off that width; without the directive, media queries are evaluated against 980 pixels and your mobile layout never kicks in at all. Writing a fixed value (width=1024, say) is worse still: every device assumes that width, narrow screens get a horizontal scrollbar, and content overflows.
Blocking zoom: the most common accessibility mistake
Adding user-scalable=no or maximum-scale=1 stops users pinching to zoom. The setting is usually added with good intentions, to keep the design from breaking or to stop the screen jumping when a form field is tapped. The cost is severe: readers with low vision need to zoom in order to read at all, and this setting shuts them out of the page entirely. WCAG 2.1 SC 1.4.4 requires at least 200% magnification; good practice allows up to 500%. A responsive design with adequate type sizes doesn't need the restriction in the first place. It's reported as a straight failure in accessibility audits and is one of the easiest items on any list to remove.
initial-scale, minimum-scale and maximum-scale
initial-scale sets the zoom level the page opens at; the standard value is 1, meaning the page is shown as-is with no scaling. minimum-scale and maximum-scale set the limits a user can zoom out and in to. Touching those two is rarely necessary, and pinning maximum-scale to a low value creates the accessibility problem described above. The practical advice: write initial-scale=1 and leave the other two undefined.
Notched screens: viewport-fit=cover
On screens with a notch or rounded corners, the browser keeps content inside the safe area by default and leaves margins at the edges. viewport-fit=cover removes that boundary and lets the design spread across the whole screen. Adding it on its own is risky, though: content can end up hidden under the notch or the home indicator. The correct usage pairs cover with safe-area variables in CSS, such as env(safe-area-inset-top), to protect the critical elements.
The on-screen keyboard and interactive-widget
When a form field is tapped on mobile, the on-screen keyboard that opens can cover close to half the visible area. The interactive-widget directive controls how that narrowing is reflected in CSS and JavaScript: whether the visual viewport or the content area is recalculated, or whether the keyboard simply overlays the content. On form-heavy pages it helps stop fixed-position buttons jumping when the keyboard appears. Leaving it undefined isn't a mistake; the default behavior is fine for most pages.
Your Questions
Frequently Asked Questions
What's the correct viewport tag?
For most sites there is one right line: <meta name="viewport" content="width=device-width, initial-scale=1">. Anything beyond that serves special cases and shouldn't be added unless you need it.
Does user-scalable=no hurt SEO?
There's no statement that it carries a direct ranking penalty, but accessibility audits report it as a failure and it lowers your Lighthouse accessibility score. The real issue is on the user's side: visitors with low vision can't enlarge the page, so they can't read it and they leave. A responsive design doesn't need the setting.
I have a viewport tag but the site still looks broken on mobile. Why?
The viewport tag is only the starting condition for scaling; the layout itself is built in CSS. Even with a correct tag, containers with fixed pixel widths, overflowing tables, oversized images or missing media queries will cause horizontal scrolling. This tool audits the tag; for layout overflow you need to look at the page's CSS.
Is having more than one viewport tag a problem?
Yes. Which one applies is left to the browser and the behavior becomes unpredictable. It usually comes from a theme and a plugin, or a template and a component, each outputting their own tag. Leave only one.
Aren't initial-scale and width=device-width the same thing?
No, they do different jobs. width=device-width sets the width the layout is based on; initial-scale sets the zoom level the page opens at. Defining both together also prevents the scaling inconsistencies some older browsers show when the device is rotated.
Should I add viewport-fit=cover?
Only if you want your design to spread across the entire screen. If you add it, you must protect the safe area with env(safe-area-inset-*) variables in CSS, or headings and buttons can end up under the notch or the home indicator. If you don't need it, leave it out.