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

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

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

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).
Complete the Turnstile check (it only appears once, on the first fresh test — cached results skip it) and press Test page.
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.
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.

What the score is made of

Mobile-friendly scoring thresholds
Check	Threshold / points	What this free pass can confirm
Viewport	30 points	width=device-width and zoom accessibility
Responsive CSS	20 points	@media rules in inspected CSS
Fixed widths	15 points · >400px warning	Markup-level width attributes and inline styles
Font sizes	10 points · <12px warning	CSS declarations and legacy font tags
Tap targets / horizontal overflow	Needs a rendered layout pass	Not 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.

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.

Where this tool helps

Common use cases

Preflight a responsive page

Check viewport configuration, responsive CSS, fixed widths, font sizes, images, weight, and plugins before release.

Troubleshoot mobile layout problems

Use the seven-part diagnostic to narrow down why a public page is difficult to read or use on a phone.

Review a phone-width preview

Inspect the separate viewport preview for visual clues while remembering it is not a substitute for real-device testing.

Verify a template fix

Rerun a representative page after changing CSS or markup and confirm which observed checks improved.

Watch the full workflow

Mobile-Friendly Tester walkthrough

Read the transcript