Is Google's Mobile-Friendly Test still available?

No. Google retired the Mobile-Friendly Test tool, its API and Search Console's Mobile Usability report in December 2023 and points people to Lighthouse instead. This page checks the same core things — viewport, horizontal scrolling, text size and tap targets — for an HTML file, without needing a public URL.

What makes a page mobile-friendly?

Four things. A tag so the phone lays the page out at its own width; nothing wider than the screen, so there is no sideways scrolling; body text that is at least 12px on screen; and links and buttons big enough to tap — WCAG 2.2 asks for at least 24×24 CSS pixels.

Why does my HTML page look tiny on my phone?

It almost always has no viewport meta tag. Without one, mobile browsers lay the page out 980 pixels wide — the width of an old desktop — and shrink the result to fit a 390-pixel screen, so every font ends up about 40% of its size. Add the viewport tag and give fixed-width containers a max-width of 100%.

Can I test a URL instead of HTML?

This tool takes HTML, so it works for files that aren't online yet: an exported report, an email template, an agent's output. For a live site, open it, view the source and paste it — or run Lighthouse in Chrome DevTools and read its JSON in the Lighthouse report viewer.

No. Each phone preview is a sandboxed iframe on this page, built in your browser. The HTML only leaves your machine if you click “Get a shareable link” and create a report.

How close is this to a real phone?

Each frame is laid out at the phone's real CSS width — 360, 393 and 430 pixels — by your own browser, and a page without a viewport tag is laid out at 980 pixels and scaled down the way a phone does it. It doesn't reproduce engine differences (Safari on iOS versus Chrome here), installed fonts, or the on-screen keyboard, so check anything critical on a device too.

Free tool

Mobile-friendly test.

Paste HTML or drop an .html file and see it on three phone screens at once — with the checks Google’s retired Mobile-Friendly Test used to run: viewport, sideways scrolling, text size and tap targets. No URL needed, nothing uploads.

index.html

<!doctype html>
<html>
<head>
<title>Q3 pipeline review</title>
<style>
  body { font: 14px/1.5 Georgia, serif; margin: 0; color: #191815; background: #faf8f3; }
  .wrap { width: 760px; margin: 0 auto; padding: 32px; }
  h1 { font-size: 26px; margin: 0 0 6px; }
  .meta { color: #6b665c; font-size: 13px; }
  table { border-collapse: collapse; margin: 20px 0; }
  th, td { border-bottom: 1px solid #e3ded3; padding: 6px 14px; text-align: right; white-space: nowrap; }
  th:first-child, td:first-child { text-align: left; }
  .actions a { display: inline-block; font-size: 11px; padding: 2px 4px; margin-right: 4px; background: #eee; border-radius: 3px; color: #191815; text-decoration: none; }
  .note { font-size: 11px; color: #6b665c; }
</style>
</head>
<body>
<div class="wrap">
  <h1>Q3 pipeline review</h1>
  <p class="meta">Prepared for the Monday revenue meeting</p>
  <table>
    <tr><th>Region</th><th>Open deals</th><th>Weighted</th><th>Won</th><th>Lost</th><th>Win rate</th></tr>
    <tr><td>North America</td><td>142</td><td>$1,284,000</td><td>38</td><td>51</td><td>42.7%</td></tr>
    <tr><td>EMEA</td><td>96</td><td>$812,500</td><td>22</td><td>40</td><td>35.5%</td></tr>
    <tr><td>APAC</td><td>57</td><td>$402,900</td><td>14</td><td>19</td><td>42.4%</td></tr>
  </table>
  <p class="actions"><a href="#na">NA</a><a href="#emea">EMEA</a><a href="#apac">APAC</a></p>
  <p class="note">Weighted = deal value × stage probability. Source: CRM export, 30 Sep.</p>
  <p class="note">Win rate excludes deals closed as duplicate or disqualified.</p>
</div>
</body>
</html>

1.5 KBStays in your browser — nothing uploads.

Checking on three phone sizes…

Viewport meta tag — Fail
No <meta name="viewport"> tag. Phones lay the page out 980 px wide and shrink it to fit, so everything renders tiny.
No sideways scrolling — Checking
Measuring…
Text at least 12px on screen — Checking
Measuring…
Tap targets at least 24×24px — Checking
Measuring…

Galaxy S23 · 360×780

iPhone 15 · 393×852

iPhone 15 Pro Max · 430×932

Need someone to read it on their phone?

Send a link instead of an attachment. It opens in any mobile browser — no Files app, no “open with” — and readers can comment on a line or a chart. Free, no card.

How to fix what it finds

No viewport tag

Put this in <head>. Without it, phones lay the page out 980 pixels wide and shrink the whole thing to fit, which is why a report that looks fine on a laptop arrives unreadably small. Don’t add user-scalable=no or maximum-scale=1 — they stop readers zooming in.

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

Sideways scrolling

The test names the widest elements. The usual culprits are a container with a fixed width, images at their natural size, long unbroken strings (URLs, hashes), and data tables. Cap containers instead of fixing them, and give tables their own scroller so only the table moves:

.wrap { width: auto; max-width: 760px; }
img, svg, video, canvas { max-width: 100%; height: auto; }
pre, code { overflow-wrap: anywhere; }

<div style="overflow-x: auto"><table>…</table></div>

Small text and small tap targets

Body text of 16px with footnotes no smaller than 12px reads comfortably on a phone. Links styled as buttons, icon buttons and pagination need at least 24×24px of tappable area (WCAG 2.2, success criterion 2.5.8) — 44px is the comfortable size. Padding counts, so padding: 10px 12px on a small link usually fixes it.

What happened to Google’s test

Google shut down the Mobile-Friendly Test, its API and the Mobile Usability report in Search Console in December 2023. Its advice now is to use Lighthouse, which needs a page loaded in Chrome. That leaves a gap for HTML that isn’t online — a generated report, an email, an agent’s output, a file someone sent you. This page fills it. For a live URL, run Lighthouse and read the result in the Lighthouse report viewer.

When the problem is the phone, not the page

If the page passes here but still opens as code, blank or unstyled on a phone, it’s how the file got there: an attachment preview showing source, or sibling CSS and JavaScript that never travelled with it. See opening an HTML file on iPhone, on Android, and HTML report tiny on a phone.

Questions

Is Google's Mobile-Friendly Test still available?: No. Google retired the Mobile-Friendly Test tool, its API and Search Console's Mobile Usability report in December 2023 and points people to Lighthouse instead. This page checks the same core things — viewport, horizontal scrolling, text size and tap targets — for an HTML file, without needing a public URL.
What makes a page mobile-friendly?: Four things. A <meta name="viewport" content="width=device-width, initial-scale=1"> tag so the phone lays the page out at its own width; nothing wider than the screen, so there is no sideways scrolling; body text that is at least 12px on screen; and links and buttons big enough to tap — WCAG 2.2 asks for at least 24×24 CSS pixels.
Why does my HTML page look tiny on my phone?: It almost always has no viewport meta tag. Without one, mobile browsers lay the page out 980 pixels wide — the width of an old desktop — and shrink the result to fit a 390-pixel screen, so every font ends up about 40% of its size. Add the viewport tag and give fixed-width containers a max-width of 100%.
Can I test a URL instead of HTML?: This tool takes HTML, so it works for files that aren't online yet: an exported report, an email template, an agent's output. For a live site, open it, view the source and paste it — or run Lighthouse in Chrome DevTools and read its JSON in the Lighthouse report viewer.
Is my HTML uploaded?: No. Each phone preview is a sandboxed iframe on this page, built in your browser. The HTML only leaves your machine if you click “Get a shareable link” and create a report.
How close is this to a real phone?: Each frame is laid out at the phone's real CSS width — 360, 393 and 430 pixels — by your own browser, and a page without a viewport tag is laid out at 980 pixels and scaled down the way a phone does it. It doesn't reproduce engine differences (Safari on iOS versus Chrome here), installed fonts, or the on-screen keyboard, so check anything critical on a device too.