Overview
Introduction
"Is this page mobile-friendly" is really a rendering question - how does the layout actually look and behave on a small screen - and a static, client-side site has no way to answer that directly since it can't run a real browser engine to measure it. What it can do is check the HTML signals that strongly correlate with mobile-friendliness or its absence: whether a viewport tag exists and is configured sanely, and whether any @media rules are visible in the markup itself.
This tool runs that heuristic check honestly, labeling every result as an HTML signal rather than a verified layout outcome, and points to Google's own rendering-based tools for the authoritative check.
What Is Mobile-Friendliness Checker?
A heuristic mobile-signal checker that inspects a page's <meta name="viewport"> tag for presence and common misconfigurations, notes the informational format-detection tag, and scans the raw HTML for @media rules or media-conditional stylesheet links as a weak indicator of responsive CSS.
It works two ways: fetching a URL directly from your browser when the target allows cross-origin requests, or reading HTML you paste in yourself, which works on any page regardless of CORS.
How Mobile-Friendliness Checker Works
The HTML is parsed with the browser's DOMParser to read the viewport meta tag's content attribute, which is then checked for width=device-width and for zoom-blocking directives (user-scalable=no, or a maximum-scale value fixed at 1). Each condition maps to a specific status: missing, warning, or good, with an explanation of the practical consequence.
Separately, a regex scans the full raw HTML text (not just parsed meta tags) for the literal string @media or a media attribute matching common responsive patterns like "only screen" or "(max-width", which only catches CSS that happens to live inline in the fetched document rather than in an external stylesheet.
When To Use Mobile-Friendliness Checker
As a fast first pass when auditing a page, to immediately catch an obviously missing viewport tag or an accidental zoom-blocking directive before reaching for a full rendering-based test.
When reviewing a page built by an unfamiliar template or third-party landing-page builder, since some older or poorly maintained builders still ship a fixed-width viewport tag or a maximum-scale=1 leftover from an older no-zoom design pattern.
Often used alongside Meta Tag Checker and Core Web Vitals Report Analyzer.
Features
Advantages
- Catches the two most common viewport misconfigurations (missing tag, zoom-blocking directive) instantly from raw HTML, without waiting on a full page render.
- States its own scope honestly - every result is framed as a signal, not a verified layout outcome, so it can't be mistaken for a substitute for an actual rendering test.
- Flags the zoom-blocking accessibility issue specifically, which purely visual mobile checks often miss since a fixed-scale page can still look fine at a glance.
Limitations
- Cannot render or measure actual layout - it has no way to detect overlapping elements, tiny tap targets, or horizontal scrolling caused by a fixed-width element, all real mobile-usability problems that only show up in an actual render.
- The @media regex scan only sees CSS present in the fetched/pasted HTML itself; it's blind to the external stylesheets that hold the vast majority of real-world responsive CSS, so a 'not found' result proves nothing either way.
Examples
Best Practices & Notes
Best Practices
- Use a plain <meta name="viewport" content="width=device-width, initial-scale=1"> and nothing more - there is essentially never a legitimate reason to add a maximum-scale or user-scalable=no restriction on top of it.
- Confirm actual mobile layout with a real rendering tool (Chrome DevTools device mode, or Google's PageSpeed Insights) after this tool's HTML-signal check passes, since HTML signals alone can't catch layout-level problems.
Developer Notes
The @media/responsive regex check is intentionally conservative and explicitly labeled a weak signal in both the UI and this content, since most production sites load their CSS from external files this client-side tool has no way to fetch or evaluate.
Mobile-Friendliness Checker Use Cases
- Quickly checking whether a page has a viewport meta tag at all before doing a deeper mobile audit
- Catching an accidental zoom-blocking viewport directive left over from an old design pattern
- Spot-checking a third-party landing-page template for basic mobile-readiness signals before adopting it
Common Mistakes
- Assuming a page passes 'mobile-friendly' because it has some viewport meta tag present, without checking that it actually includes width=device-width.
- Copying a maximum-scale=1 or user-scalable=no directive from an old template without realizing it blocks pinch-zoom for every visitor, including those who need it most.
Tips
- Follow up any warning from this tool with Google's own rendering-based Mobile-Friendly guidance and PageSpeed Insights before concluding a page is or isn't mobile-friendly.