How to Fix User-Scalable and Maximum-Scale Lighthouse Errors

These Lighthouse viewport errors show up when your page’s meta name="viewport" settings prevent users from zooming. The fix is usually a one-line change, but it matters because pinch-to-zoom is a core accessibility fallback for people who need larger text or UI. In your head tag, remove user-scalable=no (or user-scalable=0) and avoid a restrictive maximum-scale; if you must set one, keep it at 5 or higher alongside width=device-width and initial-scale=1. After updating, rerun the Lighthouse accessibility audit and test zooming on real mobile browsers, since the most common “mystery” failures come from duplicate viewport tags or a framework template you forgot to override.

Lighthouse meta viewport errors: user-scalable=no and maximum-scale too low

Common audit messages and variants

In Lighthouse, this issue usually appears in the Accessibility report with wording like “Zooming and scaling must not be disabled.” Under the hood, the failure often shows up as a specific rule statement: [user-scalable="no"] is used in the <meta name="viewport"> element or the [maximum-scale] attribute is less than 5.

Common real-world variants that trigger the same Lighthouse error include:

• user-scalable=no or user-scalable=0 inside the viewport content.
• maximum-scale=1 (or 2, 3, 4), which caps zoom below what Lighthouse expects.
• Viewport strings generated by themes or frameworks that add “mobile app-like” restrictions by default, even when you did not intend to block zoom.

If you want to confirm the exact phrasing Lighthouse uses in your version of Chrome, the Lighthouse accessibility score page lists the audit and its pass condition.

What Lighthouse considers a failure

Lighthouse treats your page as failing when the viewport meta tag prevents users from zooming or limits zoom too aggressively:

• Any user-scalable=no (or equivalent) is considered a failure because it can disable pinch zoom, which many people rely on for readability.
• If you include maximum-scale, Lighthouse expects it to be at least 5 (roughly allowing up to 500% zoom). Anything lower is flagged.

It is also worth separating this from a different Lighthouse best-practice audit about missing width=device-width and initial-scale=1. That one is about mobile viewport sizing, not zoom restrictions.

For a clear overview of viewport attributes and why disabling zoom is discouraged, the MDN viewport meta tag reference is a solid baseline.

Why disabling zoom fails accessibility and compliance checks

Who is affected by blocked zoom

Blocking zoom is rarely a “power user” feature. It is an everyday accessibility need.

People with low vision often rely on pinch zoom or browser zoom when text is too small, contrast is borderline, or UI controls are cramped. Many users also need zoom temporarily, like when they are in bright sunlight, dealing with screen glare, or using a smaller device than you designed for. Even users without a diagnosed impairment may depend on zoom after eye surgery, during migraines, or simply when they forgot reading glasses.

From a standards perspective, disabling zoom can undermine WCAG-based requirements because it removes a core fallback for resizing content. WCAG expects that users can increase text size significantly without losing content or functionality, including up to 200% for text resizing in WCAG 2.2 Success Criterion 1.4.4 (Resize Text).

Situations where zoom restrictions backfire

Zoom locks are often added to prevent layout “breakage,” but they tend to create bigger issues than they solve:

• Forms and checkout flows: Users cannot zoom into small inputs, error text, or validation hints, which increases abandonment and support tickets.
• Dense dashboards: Tables, filters, and charts become harder to interpret when users cannot magnify key values.
• Fixed headers and overlays: When users cannot zoom, they often switch to system-wide display scaling or accessibility settings, which can expose the same layout bugs anyway.
• Embedded experiences: Iframes, in-app webviews, and cookie banners can become unreadable when zoom is restricted, especially on iOS Safari.

In 2026, this also shows up in automated compliance workflows. Many teams run Lighthouse checks in CI, and AI-assisted QA tools increasingly flag the same zoom-blocking patterns. Allowing zoom is one of the simplest ways to reduce accessibility risk without redesigning your entire UI.

Fixing the viewport meta tag to allow zoom

Recommended viewport tag for most sites

For most websites, the safest fix is also the simplest: use a viewport tag that sets mobile sizing correctly while not restricting user zoom.

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

This keeps your layout responsive and leaves pinch-to-zoom and browser zoom available. If your site uses full-bleed layouts on iPhones with notches, you may also add viewport-fit=cover, but only if you are already handling safe areas in CSS.

If you are unsure which attributes are doing what, MDN’s <meta name="viewport"> reference is the most reliable baseline.

Before and after code snippets

A common failing example (what Lighthouse flags):

<!-- Before (fails Lighthouse accessibility) -->
<meta name="viewport"
 content="width=device-width, initial-scale=1, user-scalable=no, maximum-scale=1">

A typical passing fix:

<!-- After (recommended) -->
<meta name="viewport" content="width=device-width, initial-scale=1">

If you have a legacy reason to keep maximum-scale, make sure it is not overly restrictive. Lighthouse commonly flags values under 5:

<!-- Acceptable only if you truly need it -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=5">

What to remove vs what to keep

Remove (in almost all cases):

• user-scalable=no (or user-scalable=0)
• maximum-scale=1 (and other low caps), plus any minimum-scale that limits zoom

Keep:

• width=device-width to prevent “desktop-width then shrink” rendering on phones
• initial-scale=1 to start at a sensible default zoom level

Also make sure you have only one viewport tag in your <head>. One correct tag can still fail if a second one overrides it.

Cases that still fail after changes: duplicate tags and overrides

Multiple meta viewport tags in head

The most common “I fixed it but Lighthouse still fails” situation is having two (or more) viewport tags. Browsers can behave inconsistently when multiple viewport directives exist, and Lighthouse will still flag the page if it detects a zoom-blocking tag anywhere in the final HTML.

What to check quickly:

• View Page Source and search for name="viewport".
• Inspect the live DOM in DevTools Elements and search again. Some setups render a different head at runtime.
• Make sure there is only one viewport tag, and that it does not include user-scalable=no or a low maximum-scale.

Also watch for subtle duplicates like one tag in a base layout and another in a per-page template.

Framework or CMS template overwrites

Frameworks and CMS themes often manage <head> for you, which can lead to overwrites.

Typical causes:

• A CMS theme header file hardcodes a restrictive viewport tag, and your plugin or custom code adds a second “correct” one.
• A component-based framework sets head tags per route. A single page might reintroduce maximum-scale=1 while others are fine.
• Server-rendered pages and client-side hydration disagree, so the initial HTML differs from what Lighthouse ends up evaluating.

The fix is usually to centralize the viewport tag in one place (base layout, theme header, or global head component) and remove every other definition.

Third-party scripts injecting viewport settings

Less common, but real: a third-party script can inject or modify viewport settings to mimic an “app-like” feel or to control zoom during a specific flow.

This shows up with:

• A/B testing tools that swap templates, including head markup
• Embedded widgets (chat, booking, payments) that modify the head
• Legacy mobile scripts that “optimize” scaling by forcing user-scalable=no

If Lighthouse keeps failing, compare a clean page load (no extensions, no experiments) with your normal production setup. If a script is injecting the tag, fix it at the source or block that behavior with a safer integration.

How to verify the fix in Lighthouse and real zoom tests

Rerun Lighthouse and confirm the audit passes

After you update the viewport meta tag, rerun Lighthouse on the exact URL that previously failed. In Chrome DevTools, open Lighthouse, select Accessibility, then run the audit again (mobile mode is usually where viewport issues are most obvious). You want the specific audit “Zooming and scaling must not be disabled” to switch from Fail to Pass.

If it still fails, assume the fix is being overridden. The fastest confirmation is to inspect the final HTML that Lighthouse analyzed:

• In DevTools, search the <head> for name="viewport".
• Confirm there is only one viewport tag.
• Confirm it does not include user-scalable=no and does not cap maximum-scale too low.

If you run audits in CI (or via monitoring tools like Screpy), retest after deployment, not just locally. A CDN, template, or tag manager can reintroduce a second viewport tag in production.

Mobile pinch zoom and iOS Safari behavior

Do at least one real-device test. Emulation can miss gesture quirks.

On iOS Safari, verify you can pinch open to zoom in and pinch close to zoom out, and that text and controls remain usable while zoomed. Apple documents how iOS Safari handles viewport configuration and scaling behavior, including how scale settings can affect orientation changes. Configuring the Viewport

Also test Android Chrome pinch zoom. Some sites “pass Lighthouse” but still break in practice due to fixed headers, overlays, or content that cannot reflow.

Desktop browser zoom expectations

On desktop, check standard browser zoom (Ctrl/Cmd + and Ctrl/Cmd -). The page should remain readable and functional at higher zoom levels, especially around 200% and beyond. If your layout falls apart, fix the layout. Do not disable zoom as a workaround. That tradeoff usually creates bigger accessibility and conversion problems than it prevents.

Layout breaks at 200 to 500 percent: better fixes than disabling zoom

Reflow and responsive layout adjustments

If your UI “breaks” when users zoom, the problem is almost never zoom itself. It is usually a layout that cannot reflow. Aim for pages that stay functional as content gets larger and the viewport effectively gets smaller.

Focus on these fixes first:

• Use flexible layouts (Flexbox or Grid) that can wrap instead of forcing a single row.
• Avoid fixed heights on containers that hold text. Let them grow naturally.
• Prefer fluid widths (max-width: 100%) for images, tables, and embeds.
• Allow long strings to wrap (product SKUs, URLs, email addresses) so they do not force horizontal scrolling.

This aligns with the intent of WCAG Success Criterion 1.4.10 (Reflow), which is a useful north star when you are testing zoom and responsive behavior.

Overflow and fixed-position pitfalls

Zoom problems often come from a few repeat offenders:

• overflow: hidden on the body or main wrapper, which can clip content when it grows.
• Sticky headers and fixed toolbars that take too much vertical space at higher zoom.
• Modals and cookie banners that are not scrollable, trapping users when the dialog exceeds the viewport.
• Flex children without min-width: 0, which can prevent text from shrinking and wrapping inside a row.

When you find horizontal scroll at high zoom, fix the element that is exceeding the viewport instead of globally disabling zoom.

Input and text sizing that stays usable

Make zoom the fallback, not the primary strategy. Use readable defaults:

• Use relative units (rem, em) for typography and spacing.
• Ensure tap targets and form controls stay comfortable on mobile.
• Do not rely on placeholder text as a label. It becomes harder to use as users zoom and pan.

A practical check: can someone complete your main form while zoomed, without losing error messages or action buttons?

Safer alternatives for kiosks and embedded WebViews

If you truly have a controlled environment (kiosk screens, POS terminals, in-app webviews), avoid “zoom locks” as your first tool. Safer options include:

• Provide a built-in text size control in the UI.
• Use a kiosk-specific stylesheet that increases base font size and spacing.
• For embedded webviews, prefer native container settings and clear user controls over restrictive viewport rules.

In 2026, this also helps with AI-driven QA and monitoring. Automated accessibility checks, including LLM-assisted audits, are more likely to flag zoom restrictions than a responsive reflow fix.