Mobile Friendly Tester

Enter a URL and the tester loads it in a simulated phone viewport (375×812 by default, iPhone sizing), checks for the common mobile-readability failures Google’s own Mobile-Friendly Test used to flag before it was retired, and returns a list you can fix: missing viewport meta tag, text smaller than 12px, tap targets closer than 48×48 px, horizontal scroll, Flash/unsupported plugins, and content wider than the viewport.

How the test runs

  1. 1

    Enter the URL

    Full URL with protocol. Public pages only.

  2. 2

    Page renders in a phone-size viewport

    375×812 by default, configurable.

  3. 3

    Automated checks run

    Viewport meta, text size, tap target spacing, overflow, plugins.

  4. 4

    Preview and report

    Screenshot of the rendered phone view plus a list of specific issues.

What the tester checks

Viewport configuration

  • Is there a <meta name="viewport" content="width=device-width, initial-scale=1">? Without it, mobile browsers render as if the phone were desktop-width and shrink to fit, producing tiny text.

Text size

  • Any rendered text below 12 px is flagged, hard to read on phone without pinch-zoom.
  • Many style guides recommend 16 px body minimum. Very small captions are OK; body copy at 11 px is not.

Tap target size

  • Buttons, links, form controls should be at least 48×48 px (Google / W3C mobile accessibility guideline).
  • Smaller targets are hard to hit accurately with a thumb and are flagged.

Tap target spacing

  • Targets closer than 8 px to adjacent targets produce mis-taps. Flagged individually.

Horizontal scroll

  • Content wider than the viewport forces horizontal swipe, poor mobile UX. Usually caused by an image without max-width: 100% or a table that can’t reflow.

Unsupported plugins

  • Flash, Silverlight and ActiveX don’t work on phones. Legacy sites sometimes still reference them.

Font loading

  • Very large web fonts that block rendering for seconds are flagged.

Why it still matters

Google discontinued its standalone Mobile-Friendly Test in December 2023, but mobile-friendliness remains a direct ranking signal via Core Web Vitals and page-experience metrics. Mobile-first indexing means Google crawls your site as a phone; what breaks on mobile shows up in desktop rankings too.

Typical fixes

  • Add viewport meta to <head>: <meta name="viewport" content="width=device-width, initial-scale=1">.
  • Responsive CSS via media queries: @media (max-width: 768px) { ... }.
  • Flexbox and Grid rather than fixed-width layouts.
  • Set image max-width: 100%; height: auto so images shrink with the viewport.
  • Make tables scrollable on small screens: wrap in <div style="overflow-x: auto">.
  • Use rem or em for text sizing so user-preference scaling works.

What the tester doesn’t catch

  • Performance on real hardware. A low-end Android phone on 3G experiences delays this tester doesn’t simulate. Use Lighthouse for performance.
  • Touch interactions. Hover-only dropdowns that break on touch need manual testing on a real device.
  • Accessibility beyond mobile sizing. Contrast, screen reader support, keyboard navigation, use dedicated accessibility tools.
  • JavaScript errors on mobile-specific browsers. Safari on iOS sometimes behaves differently than other WebKit builds.

Frequently Asked Questions

Similar checks, different implementation. Google retired its public tool in late 2023. This tester runs the same set of classic checks Google used, against the version of the page a headless browser fetches.

Yes, Google has indexed mobile-first since 2020, meaning your mobile rendering is the primary version for ranking. Mobile issues hurt rankings even on desktop searches.

No. The tester fetches publicly-accessible URLs only. For protected staging, test locally with Chrome DevTools’ device emulation mode.

Default is 375×812 (iPhone 12/13/14). Configurable to 390×844 (iPhone 14 Pro), 360×640 (common Android), or 412×915 (Pixel 7).

Typically 5–15 seconds depending on page weight. Heavy pages with many scripts take longer; the tester waits for the load event plus a brief idle period before capturing.

Related Tools

Tool available in other languages