Mobile-Friendly Tester

Free, no signup. Run this tool's seven weighted mobile-layout checks and get a 0–100 diagnostic score, plus a phone-viewport preview as separate supporting evidence.

Built by Patrick Stox

Free, no sign-up. The analysis reads your HTML the way a mobile browser would; the screenshot renders in headless Chrome on a 390×844 iPhone-sized viewport.

Checks run from our server; we fetch the URL you enter and don't keep the results. Results are kept in a short-lived cache, not stored long-term. Anonymous aggregate stats feed our research posts; domains are counted once via an anonymized hash and never stored in the clear. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Mobile Friendly Tester? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
 
 
Sample report
 
Say you test a page whose <head> and markup look like this:
 
 
<head>
  <meta name="viewport"
        content="width=device-width, initial-scale=1, user-scalable=no">
  <link rel="stylesheet" href="/styles/site.css">   <!-- has @media rules -->
</head>
<body>
  <div style="width:960px">…fixed-width wrapper…</div>
</body>
 
 
…and the tool returns a score of 78 with these checks
          (computed by running this page's own scorer against the signals above):
 
Example data — captured by running this page's own scoring engine against the markup above
 
 
    78  
 
Mostly mobile-friendly
 
https://example.com/your-page
 
 
 
 
 
warn
Viewport meta tag
 24/30 pts
 
Viewport is set, but zooming is disabled — this hurts accessibility.
 
 
 
warn
Content sized to viewport
 9/15 pts
 
1 element(s) with fixed widths over 400px — likely to cause horizontal scrolling.
 
 
 
info
Responsive CSS
 10/20 pts
 
No CSS was inspectable, so responsiveness couldn't be verified.
 
 
 
pass
Legible font sizes
 10/10 pts
 
No inline font sizes below 12px detected.
 
 
 
 
     
  • The linked stylesheet is the info row, not a pass — this static example never
            actually fetches /styles/site.css, so the tool honestly reports it couldn't verify
            responsiveness rather than assuming media queries exist. A live run against a real URL fetches
            up to four stylesheets to check. See what info vs. pass means ↓.
    •  
  • Two fixable warnings hold the score at 78: user-scalable=no blocks
            pinch-zoom (drop the viewport back to width=device-width, initial-scale=1), and the
width:960px wrapper will overflow a 390px screen (swap it for max-width:100%).
    •  
  • The three unlisted checks all passed (responsive images, page weight, no legacy
            plugins) — full marks there, which is why total score is 78, not lower.
    •  
  • Fixing the viewport and the fixed-width wrapper — and getting the stylesheet actually inspected —
            would push this into the green Mobile-friendly band. Compare against the
Core Web Vitals Checker if slow mobile
            loading is also a concern.
    •  
 
 
 
How to use it
 
     
  1. Paste the full URL of the page you want to test — a real page, not just the homepage.
            The scheme is required (https://example.com/your-page).
    2.  
  2. Complete the Turnstile check (it only appears once, on the first fresh test — cached
            results skip it) and press Test page.
    3.  
  3. Read the 0–100 score and rating in the gauge, then work down the check
            list — failures and warnings are sorted to the top, each showing its points earned.
    4.  
  4. Compare the checks against the phone-viewport screenshot on the right
            (390×844, iPhone user agent). It loads a moment after the score and is your reality check.
    5.  
 
 
 
     
     
     
 
What the score is made of
 
 
 
 Mobile-friendly scoring thresholds  
 CheckThreshold / pointsWhat this free pass can confirm 
   
 Viewport 30 pointswidth=device-width and zoom accessibility 
 Responsive CSS 20 points@media rules in inspected CSS 
 Fixed widths 15 points · >400px warningMarkup-level width attributes and inline styles 
 Font sizes 10 points · <12px warningCSS declarations and legacy font tags 
 Tap targets / horizontal overflow Needs a rendered layout passNot claimed by this free HTML score 
  
 
 
 Source: Tool scoring contract · Updated: July 2026 
 
 
 
 
Viewport is 30 points
 
Without width=device-width, phones render your page at ~980px and shrink it to fit — every other mobile problem starts here. Disabling zoom costs points too: it’s an accessibility failure.
 
 
 
Layout checks
 
Responsive CSS (@media rules, including in external stylesheets), hard-coded widths over 400px, and sub-12px font sizes — the three classic ways a desktop layout breaks on a phone.
 
 
 
Delivery checks
 
Responsive images (srcset/<picture>), HTML page weight on mobile networks, and leftover <object>/<embed> plugin content that mobile browsers won’t run.
 
 
 
  
 

Checking why a page fails on phones? Start here, then read the
mobile-first indexing guide and the
viewport meta tag reference for the fixes.

 
What the results mean
 
The gauge colour and rating come from the total score:
 
     
  • Mobile-friendly (90–100, green) — nothing structural is holding the page back on phones.
    •  
  • Mostly mobile-friendly (70–89, olive) — works, but one or two checks are warnings worth fixing.
    •  
  • Needs work (50–69, amber) — real problems a phone user will feel.
    •  
  • Not mobile-friendly (0–49, red) — the page is likely rendering at desktop width and shrinking.
    •  
 
Each check carries a severity badge, colour-coded by its left border:
 
     
  • Pass (green) — full or near-full credit for that check.
    •  
  • Warn (amber) — partial credit; a fixable issue.
    •  
  • Errors (red) — no credit; the check found a clear mobile problem.
    •  
  • Info (blue) — half credit because the tool couldn’t inspect enough CSS to be sure
            (e.g. no stylesheet was reachable), not because the page is broken.
    •  
 
How it works
 

The score comes from a server endpoint that streams your page through a single
HTMLRewriter pass — reading the <meta name="viewport"> tag, inline
          styles, width attributes, images, <object>/<embed> elements,
          and the HTML byte count as the bytes flow by. It also fetches up to four linked stylesheets to look
          for @media rules, then weights everything into a 0–100 total. This path is fast,
          effectively free, and always runs.

 

The phone screenshot is a separate, metered step. Only a URL that already passed the analysis can
          request it, and the render draws from a shared browser-time budget with daily and monthly caps. When
          that budget is spent, the renderer is busy, or the page blocks headless browsers, the preview shows a
          calm note and your score is untouched — the two never depend on each other.

 
The seven checks
 
     
  • Viewport meta tag — 30 pts. width=device-width present and zoom
            allowed. The heaviest check because every other mobile behaviour depends on it.
    •  
  • Responsive CSS — 20 pts. At least one @media rule, checked in inline
<style> blocks and in the linked stylesheets.
    •  
  • Content sized to viewport — 15 pts. No hard-coded widths over 400px (inline style
            or width attribute) that would force horizontal scrolling.
    •  
  • Legible font sizes — 10 pts. No inline font sizes under 12px and no legacy
<font size> tags.
    •  
  • Responsive images — 10 pts. Images use srcset/sizes so
            phones don’t download desktop-sized files.
    •  
  • HTML page weight — 10 pts. The HTML document’s byte size — smaller loads faster on
            mobile networks.
    •  
  • No incompatible plugins — 5 pts. No <object>/<embed>
plugin content that mobile browsers won’t run.
    •  
 
Limitations
 

The score is static analysis, so it does not run JavaScript — CSS applied at runtime
          by a framework isn’t counted, which is exactly why the phone screenshot is there to cross-check.
          Responsive CSS is inferred from the presence of @media rules (in the HTML and up to four
          stylesheets), not from actually laying the page out, so a page with unusual responsive techniques can
          read lower than it deserves. It tests one URL a public crawler can reach — login-gated or blocked
          pages, and very large pages past the byte cap, are analysed only up to that cap. It also isn’t a
          Core Web Vitals or tap-target-spacing test; for field performance use the
Core Web Vitals Checker.

 
Frequently asked questions
 
Google retired its Mobile-Friendly Test — is this a replacement?
Google removed the standalone Mobile-Friendly Test and the mobile-usability report in Search Console in late 2023. This tool applies its own seven-part diagnostic model. Those checks are product heuristics for finding likely mobile-layout problems, not Google eligibility criteria or a replacement for testing on real devices.
Does the test render JavaScript?
The 0–100 score comes from a static-analysis pass over the HTML and up to four stylesheets, so it does not execute JavaScript. The phone screenshot is a headless-Chrome preview and useful supporting evidence, but it is still one viewport and one rendering environment. Treat disagreements as a prompt to inspect the page and test representative real devices.
Why did I lose 30 points for the viewport tag?
The viewport check is worth 30 of the 100 points because it is the single setting every other mobile behaviour depends on. With no <meta name="viewport"An HTML head element — <meta name="viewport" content="width=device-width, initial-scale=1"> — that hints mobile browsers to size the layout viewport to the device's width in CSS pixels instead of a legacy ~980px fallback, so responsive design works.> tag, phones render your page at roughly 980px wide and shrink it to fit, so text is tiny and taps miss. The fix is one line in the <head>: <meta name="viewport" content="width=device-width, initial-scale=1">. Disabling zoom (user-scalable=no or maximum-scale=1) keeps most of the credit but drops to a warning because it is an accessibility failureWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all..
What counts as a fixed-width element?
The "Content sized to viewport" check flags any element with a hard-coded width over 400px — either an inline style:width or a width="…" attribute. Those are the widths most likely to overflow a phone screen and force horizontal scrolling. One or two is a warning; three or more is a fail. Use max-width with a percentage or relative units instead so blocks shrink on small screens.
The screenshot says "unavailable" but I still got a score — is that a bug?
No. The score and the seven checks come from the free HTML analysis, which runs first. The phone screenshot is a separate, metered render that can be skipped when a self-imposed daily or monthly cost cap is reached, when the renderer is briefly busy, or when the page blocks headless browsers. In every one of those cases the note is deliberately calm and your score is unaffected — the analysis never depends on the screenshot.
 
 
 
        
Explore more
ToolAccessibility TesterToolHTTP Header CheckerToolDNS CheckerArticleResponsive Web DesignArticleMobile UsabilityArticleDynamic Serving
 
 
 
Feature requests for Mobile Friendly Tester
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
          
 
Common issues & how to fix them
  
     
  •  Errors Viewport meta tag is missing or invalid Fix: Add a valid width=device-width viewport meta tag to the initial HTML head. 
  •  Warnings Responsive CSS signals are missing Fix: Add responsive CSS breakpoints that adapt layout and typography to narrow viewports. 
  •  Errors Fixed-width content exceeds the viewport Fix: Replace viewport-breaking fixed widths with fluid max-width, percentage, grid, or flex sizing. 
  •  Warnings Text is too small for mobile reading Fix: Raise mobile body text to a readable base size and avoid essential text below 12 CSS pixels. 
  •  Warnings Images are not sized responsively Fix: Constrain images with max-width:100% and height:auto, and provide responsive sources where useful. 
  •  Warnings HTML page weight is high Fix: Remove unnecessary inline payload, compress assets, and defer noncritical resources to reduce mobile transfer cost. 
  •  Errors Incompatible plugin content is present Fix: Replace Flash, Java applets, or other unsupported plugin content with native HTML, CSS, and JavaScript. 
    •