Is anything uploaded?

No. Parsing is local in your browser and clears on refresh.

Should I disable user zoom?

Usually no. Disabling zoom can create accessibility problems for low-vision users and should be avoided on normal content, marketing, and documentation pages.

Does this test Core Web Vitals or layout quality?

No. This is a structural viewport check. Use Lighthouse, field data, mobile screenshots, and device testing for performance and layout behavior.

web validator

Viewport Meta SEO Validator

Validate rendered viewport meta tags for mobile-friendly indexing, responsive rendering, Core Web Vitals QA, and accessible zoom behavior before launch.

Results

Paste input and validate locally.

Status: Ready when you validate.
Details: Ready when you validate.
Width: Ready when you validate.
Initial scale: Ready when you validate.
User-scalable: Ready when you validate.
Maximum scale: Ready when you validate.
Issues: Ready when you validate.

How to use this validator

Open the page source, deployed preview, CMS output, or crawler export for the mobile page you want indexed.
Copy the rendered <head> or the viewport meta tag into the validator.
Run the check and fix missing width=device-width, invalid scale values, or zoom restrictions such as user-scalable=no.
Pair the result with HTML meta, canonical/hreflang, meta robots, Open Graph, and performance/mobile screenshots during final SEO QA.

Rules & checks

Requires width=device-width so the layout uses the device viewport instead of a fixed desktop canvas.

Validates initial-scale when present and recommends a sensible value such as 1 for predictable mobile rendering.

Warns on user-scalable=no, maximum-scale below accessible levels, and zoom restrictions that can fail accessibility expectations.

Validates rendered markup, not framework source, because CMS themes, Next.js document shells, and plugins can override the final viewport tag.

Runs fully client-side on pasted HTML; it does not fetch URLs, emulate devices, measure Core Web Vitals, or test actual responsive layout breakpoints.

Inputs explained

Rendered HTML head or viewport meta tag
Paste view-source output, a deployed preview, crawler-exported HTML, or the exact <meta name="viewport"> tag. Include the rendered head when possible so duplicate or overridden viewport tags are easier to spot during QA.

When to use it

QA landing pages, calculators, docs, and validator pages for mobile-first indexing readiness before launch.
Check CMS, ecommerce, static-site, or Next.js document shells after metadata/layout changes.
Investigate Search Console mobile usability warnings or screenshots that look zoomed-out, clipped, or desktop-scaled.
Review crawler exports before running deeper Lighthouse, Core Web Vitals, or device screenshot checks.
Support teams validating user-submitted HTML snippets without uploading markup to a third-party service.

Common errors

Missing width=device-width on responsive pages, causing narrow or desktop-width mobile rendering.
Non-numeric initial-scale values copied from malformed CMS templates.
user-scalable=no blocking pinch zoom for low-vision users.
maximum-scale set too low, creating accessibility and usability issues.
Duplicate viewport tags where plugins or layout shells override the intended setting.
Testing source components instead of the final rendered HTML that crawlers and mobile browsers see.

Limitations

Structural viewport check only; it does not measure actual layout responsiveness, tap target size, CLS, LCP, INP, or mobile screenshot quality.
Does not fetch live URLs, render JavaScript, inspect CSS breakpoints, or emulate Googlebot Smartphone.
Does not replace full accessibility, Lighthouse, browser-device, or Search Console mobile usability testing.

Tips

Use width=device-width, initial-scale=1 as the default for responsive pages.
Avoid disabling zoom unless a carefully tested app surface absolutely requires it; content pages should keep pinch zoom available.
Validate rendered HTML, not only source components, because framework document shells and CMS plugins can rewrite the viewport tag.
After this structural check, test real mobile screenshots, tap targets, layout shifts, and Core Web Vitals separately.
Use this with the HTML meta, canonical/hreflang, meta robots, Open Graph, and JSON-LD validators for a complete launch pass.

Examples

Valid responsive viewport

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

Missing device width

<meta name="viewport" content="initial-scale=1"> -> flagged because mobile browsers may render a desktop-width canvas

Zoom disabled

<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no"> -> warned because users cannot pinch zoom

Unsafe maximum scale

maximum-scale=0.5 -> flagged because it restricts accessible zoom behavior

Deep dive

Viewport configuration is one of the simplest mobile-first SEO launch checks: without width=device-width, a responsive page can still render like a tiny desktop site on phones.

Use this validator as the rendering layer after charset/lang basics and before deeper mobile QA, Core Web Vitals, screenshots, canonical/hreflang, meta robots, sitemap.xml, and structured-data checks.

Because validation runs in your browser on pasted HTML, you can inspect private previews, client CMS templates, and crawler exports without sending page markup to a server.

FAQs

Is anything uploaded?: No. Parsing is local in your browser and clears on refresh.
What viewport tag should most responsive pages use?: A safe default is <meta name="viewport" content="width=device-width, initial-scale=1">.
Should I disable user zoom?: Usually no. Disabling zoom can create accessibility problems for low-vision users and should be avoided on normal content, marketing, and documentation pages.
Does this test Core Web Vitals or layout quality?: No. This is a structural viewport check. Use Lighthouse, field data, mobile screenshots, and device testing for performance and layout behavior.

Related validators

web

HTML Meta SEO Validator

Validate rendered HTML document basics—charset, html lang, language targeting, and launch-readiness signals that support crawl, accessibility, and snippet QA.

web

Image Alt Text Validator

Check images for missing alt text to improve accessibility and SEO.

web

Canonical & hreflang Validator

Validate canonical URLs, hreflang alternates, x-default fallbacks, absolute target URLs, and duplicate-content signals before search engines cluster or localize pages incorrectly.

web

Meta Robots / X-Robots-Tag SEO Validator

Validate page-level indexability signals across meta robots, X-Robots-Tag headers, canonical targets, snippet controls, and launch noindex cleanup.

web

Open Graph & Twitter Card SEO Validator

Validate rendered Open Graph and Twitter/X card tags for search-result snippets, social previews, share-card images, absolute URLs, and launch QA before publishing.

web

JSON-LD SEO Validator & Rich Result Schema Checker

Validate rendered JSON-LD structured data for schema.org syntax, rich-result readiness, visible-content alignment, and crawlable schema blocks before publishing.

All viewport validation runs in your browser. Pasted markup is not uploaded, logged, or stored.

Structural viewport-tag check only; does not measure live rendering, mobile usability, accessibility compliance, or Core Web Vitals.