Mobile-friendly test
Check how a page works on phones: viewport, zoom, responsive CSS and fixed widths in seconds, then a Google Lighthouse run on an emulated phone with scores, touch targets, speed and a screenshot.
- Source checks that name the cause
- Lighthouse on a phone, with screenshot
- Real-user data when Google has it
Verdict
Enter a URL to start
- FetchWaiting for inputAs Chrome on Android
- Source checks—HTML and stylesheets
- Lighthouse—Rendered on a phone
- Real users—Chrome UX Report
Mobile report
Enter a page URL above to check its viewport, zoom, responsive CSS and fixed widths, and to see it rendered on a phone by Google Lighthouse with scores, touch targets and speed.
Fair-use limit for each visitor IP address: 30 source checks per hour and 200 per day, 10 Lighthouse runs per hour and 30 per day. Results are cached for 10 and 30 minutes.
What mobile-friendly means today
A page that fits the screen, can be read and tapped without zooming, and loads quickly on a phone's slower processor and network.
Google's test is gone
Google retired its Mobile-Friendly Test and the Mobile Usability report in December 2023, and points to Lighthouse instead.
Mobile-first indexing
Google crawls and indexes the mobile version of pages. Content missing on mobile is missing for Google too.
Source and rendered checks
The HTML shows causes, such as a missing viewport. A rendered test shows effects, such as small touch targets or a slow page.
Lab and field data
Lighthouse is one lab run on an emulated phone. The Chrome UX Report shows how real Chrome visitors experienced the page.
What the test checks
Source checks read the HTML; rendered checks come from Lighthouse.
| Check | Type | What it looks for |
|---|---|---|
| Viewport | Source | A viewport meta tag with width=device-width, so phones show the page at their own width. |
| Zoom allowed | Source | No user-scalable=no or low maximum-scale, so people can pinch to zoom. |
| Responsive CSS | Source | Media queries in the page and up to 3 of its stylesheets. |
| Fixed widths | Source | Inline styles, tables and iframes wider than a phone screen. |
| Tiny inline fonts | Source | Inline font sizes below 12px. |
| Mobile keyboards | Source | Email and phone fields that use the right input type. |
| Viewport and touch targets | Rendered | Lighthouse checks the rendered viewport and that targets are at least 24 by 24 CSS pixels. |
| Speed on a phone | Rendered | Lighthouse lab metrics, plus real-user Core Web Vitals when Google has them. |
How to use this tool
From a URL to a list of mobile fixes.
Enter the page URL
Any public page. Test the pages that matter most, not only the homepage.
Read the source checks
In a few seconds: viewport, zoom, media queries, fixed widths and more, with the exact cause.
Wait for Lighthouse
Google renders the page on an emulated phone: scores, speed, touch targets and a screenshot.
Fix and test again
Start with failed checks, then the slowest metrics, and test on a real phone too.
What this tool does, and what it doesn't
A plain list, so you know exactly what to expect.
This tool does
- Check viewport, zoom and media queries
- Find fixed widths and tiny inline fonts
- Run Lighthouse on an emulated phone
- Show a screenshot of the page on a phone
- Show real-user Core Web Vitals
- Export the results as CSV
This tool does not
- Replace testing on real phones
- Give Google's official verdict
- Guarantee better rankings
- Test pages behind a login
- Check every page of a site
- Store your URLs
Where your data goes
For the source check, our server fetches the page as Chrome on Android. For the Lighthouse check, the URL is sent to Google PageSpeed Insights, which loads the page from Google's servers. Results are cached for 10 and 30 minutes, and fair-use counters use a hashed IP address, as described in our privacy policy.
Why your results might look unexpected
The six situations people run into most, and what each one means.
The screenshot shows a desktop layout
The viewport tag is missing or has a fixed width, so the phone shrinks the desktop page.
Lighthouse scores change between runs
Lab results vary with the network, ads and third-party scripts. Compare a few runs.
Lighthouse is busy or times out
Google's shared quota is used up or the page is very slow. Try again in a minute.
The source check is blocked
Bot protection refused our server. The Lighthouse result, from Google, may still work.
No media queries found
The stylesheets may be on another domain, inlined by JavaScript, or more than 3.
No real-user data
The Chrome UX Report only covers pages and sites with enough Chrome visitors.
Questions about mobile-friendly pages
Is Google's own Mobile-Friendly Test still available?
No. Google retired the Mobile-Friendly Test tool, its API and the Mobile Usability report in Search Console in December 2023, and recommends Lighthouse instead. This tool combines quick checks of the page's HTML with a Lighthouse run on an emulated phone through Google PageSpeed Insights.
What makes a page mobile-friendly?
A viewport meta tag with width=device-width, a layout that adapts with CSS media queries, no content wider than the screen, text that is readable without zooming, touch targets large enough to tap, and a page that loads quickly on a phone. Visitors should also be able to pinch to zoom.
Does mobile-friendliness affect Google rankings?
Google indexes the mobile version of pages, and finished moving all sites to mobile-first indexing in 2024, so content and links must be there on mobile. Mobile usability and speed are part of page experience, which Google describes as one consideration among many, not a guarantee of higher rankings.
What is the difference between the two checks?
The source check reads the HTML and stylesheets our server receives, so it is fast and shows exactly which tag or style causes a problem. The Lighthouse check loads the page in a real browser on an emulated phone, so it sees the rendered result, including touch target sizes, speed and a screenshot, but it takes 20 to 60 seconds.
How big should touch targets be?
Lighthouse uses the target-size accessibility audit, based on WCAG 2.2, which asks for targets of at least 24 by 24 CSS pixels or enough space around smaller ones. Many design guidelines recommend about 48 by 48 pixels for comfortable tapping. Older versions of Lighthouse had a separate tap targets audit, which was replaced by target-size in Lighthouse 12.
Why are the Lighthouse scores different each time?
Lab tests vary with network conditions, server response time, ads and third-party scripts, so scores can change by a few points between runs. The real-user data from the Chrome UX Report is a 28-day average of actual Chrome visits and is more stable, but Google only has it for pages and sites with enough traffic.
Is my URL stored?
Our server fetches the page for the source check and keeps the result for 10 minutes so a repeated check is instant. For the Lighthouse check, the URL is sent to Google PageSpeed Insights, which loads the page from Google's servers; that result is kept for 30 minutes. Fair-use counters use a hashed version of your IP address, as described in our privacy policy.