Free tool Mobile-friendly test, after Google retired its own
Google switched off its Mobile-Friendly Test tool and API in December 2023 and pointed people to Lighthouse. This page runs the mobile checks that still exist in Lighthouse on an emulated phone, shows a screenshot, and checks pasted HTML locally so you can find the line to fix.
- Emulated phone + screenshot
- Only audits current Lighthouse has
- Pasted HTML stays in your browser
Check a page on a phone
Part 1 tests a live URL through Google’s PageSpeed Insights API (mobile only). Part 2, below, checks HTML you paste without sending it anywhere.
What is sent, and where
- Only when you press the button: the page URL, mobile or desktop, the report language and the API key go from your browser straight to Google (
www.googleapis.com). TapCub does not see, relay or store them. - Google's servers then load that page the way a visitor would and return the report. Google's privacy policy applies to that request.
- A key you type stays on this page. It is saved in this browser (
localStorage) only if you tick “Remember”; untick to delete it. - Networks or extensions that block www.googleapis.com — some company networks, some ad blockers, and mainland China — make the test fail with a network error.
No test run yet
Enter a URL and press the button. Real-user data and the lab test appear here. Meanwhile, these are the thresholds Google uses for real-user data:
| Metric (75th percentile) | Good | Needs improvement | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | ≤ 2.5 s | 2.5 s – 4.0 s | > 4.0 s |
| Interaction to Next Paint (INP) | ≤ 200 ms | 200 ms – 500 ms | > 500 ms |
| Cumulative Layout Shift (CLS) | ≤ 0.10 | 0.10 – 0.25 | > 0.25 |
| First Contentful Paint (FCP) · not a Core Web Vital | ≤ 1.8 s | 1.8 s – 3.0 s | > 3.0 s |
| Time to First Byte (TTFB) · not a Core Web Vital | ≤ 800 ms | 800 ms – 1.8 s | > 1.8 s |
Source: PageSpeed Insights documentation (“About PageSpeed Insights”) and web.dev, checked 2026-11-11.
Check pasted HTML (local)
Paste a page’s source or a template. This checks the viewport tag, fixed widths that cause sideways scrolling, tiny font sizes and images without dimensions — with line numbers. It reads the code; it does not render the page.
Tip: in the browser, View Source and copy everything. CSS in external files is not checked — paste it inside a <style> block if you want it included.
- ProblemLine 5The viewport is fixed at width=1024. The page is laid out at that width and scaled down on phones. Use width=device-width.
- CheckLine 5Zoom is disabled (user-scalable=no or 0). Lighthouse’s meta-viewport audit fails this: people with low vision need to zoom.
- CheckLine 92 fixed width value(s) of 500 px or more (largest 980 px). On a phone these force sideways scrolling; use max-width or percentages.
- NoteLine 102 font-size value(s) below 12 px (smallest 10 px). Hard to read on a phone without zooming; Lighthouse’s former font-size audit used 12 px as the limit.
- NoteLine 171 image(s) without width and height (or aspect-ratio). The page jumps when they load, which hurts Cumulative Layout Shift.
Share these inputs: the values go after the # in the link, so they never reach a server.
https://tapcub.com/tools/mobile-friendly-test
Version v1.0Updated Update history
What each check means for a phone
Lighthouse reports these as separate audits; together they cover what Google’s old tool used to flag that can still be tested automatically.
Viewport
Without width=device-width a phone renders the page at desktop width and shrinks it, so text is tiny and taps can be delayed. This is the single most common reason a page “isn’t mobile-friendly”.
Zoom
Blocking zoom does not make a page more mobile-friendly; it fails accessibility. Let people pinch-zoom.
Touch targets
Links and buttons need enough size and space to tap without hitting the neighbour. Lighthouse checks this with the WCAG 2.2 target-size rule; “not applicable” means no small, crowded targets were found to test.
Images and screenshot
Blurry or stretched images are flagged separately. The screenshot shows what the emulated phone actually rendered — look for sideways overflow, overlapping text and pop-ups covering content.
Lighthouse no longer checks font size or content wider than the screen. Use the screenshot, the local HTML check below the tool, and a real phone for those.
Test, look, find the line
The URL check tells you what fails; the HTML check tells you where.
-
1
Check the live URL
Enter a page and run the check. You get the screenshot and the five Lighthouse mobile audits.
-
2
Look at the screenshot
Anything cut off, overlapping or covered by a banner on the screenshot is what visitors see too.
-
3
Paste the HTML
Paste the page source or template into the local check to get line numbers for the viewport tag, fixed widths and tiny fonts.
-
4
Confirm on a real phone
Emulation is close, not identical. Open the page on an actual phone, rotate it and tap the main buttons.
What is checked, and by whom
The URL part only reports audits that exist in Lighthouse 13. The HTML part is this tool’s own rule set, based on the same guidance.
- Google retired the Mobile-Friendly Test tool, its API and the Search Console Mobile Usability report from 1 December 2023 (Google Search Central, 19 April 2023)
- Lighthouse 12 (2024) replaced the tap-targets audit with target-size; Lighthouse 13 (October 2025) replaced the viewport audit with the viewport insight and removed the font-size audit
- An audit missing from a report is shown as “not in this report”, never as passed
- The HTML check reads code only: CSS in external files and layout produced by JavaScript are not seen
| Check | Source | Flags when |
|---|---|---|
| viewport-insight | Lighthouse, performance | The viewport tag is missing or not set for mobile |
| meta-viewport | Lighthouse, accessibility (axe) | user-scalable=no, or maximum-scale below 5 |
| target-size | Lighthouse, accessibility (axe) | Touch targets too small or too close (WCAG 2.2) |
| image-size-responsive | Lighthouse, best practices | Image resolution too low for the screen |
| image-aspect-ratio | Lighthouse, best practices | Image shown at the wrong aspect ratio |
| Fixed width ≥ 500 px | This tool (HTML) | width / min-width in px that forces sideways scrolling |
| Font size < 12 px | This tool (HTML), note only | Text likely too small to read without zooming |
| Image without size | This tool (HTML), note only | No width / height or aspect-ratio: layout shift |
The “Desktop-only page” sample, checked
The first sample in the HTML box is an old fixed-width shop page. This is what the local check reports and how to fix each line.
| Line | Finding | Fix |
|---|---|---|
| 5 | Viewport fixed at width=1024 | content="width=device-width, initial-scale=1" |
| 5 | Zoom disabled (user-scalable=no) | Remove user-scalable and maximum-scale |
| 9 | Fixed width: 980 px and 960 px | max-width: 980px; width: 100% |
| 10 | Font sizes of 11 px and 10 px | At least 12 px; 16 px for body text |
| 17 | Image without width and height | Add width and height of the file |
The second sample, “Responsive page”, applies all five fixes and passes. Switch between them in the tool to compare.
Where mobile checks go wrong
Four mistakes that survive a passing test.
Looking for Google’s green badge
The old “Page is mobile-friendly” verdict is gone. Google now points to Lighthouse, which reports individual audits instead of one pass / fail.
Disabling zoom to fix layout
user-scalable=no hides layout bugs and fails accessibility. Fix the widths instead.
Fixed pixel widths
A 980 px wrapper or table forces sideways scrolling on a 390 px screen. Use max-width and let content wrap.
Trusting emulation alone
Emulators miss real fonts, browser toolbars and touch behaviour. Check key pages on a real phone too.
See how phone visitors actually fare
A mobile test checks one page once. Analytics shows who visits on phones and whether those pages are slow for them.
Device and browser breakdown
The audience view splits visitors by country, device and browser, so you know how much of your traffic is mobile.
Learn moreScreen width ranges
Visitors grouped into CSS width ranges, so you can see which narrow screens to test.
Learn moreWeb Vitals by device type
Real-user LCP, INP and CLS per page, split by device type — mobile problems do not hide behind desktop averages.
Learn moreMobile-friendly test FAQ
Still have a question?
Chat with the team behind TapCub — we usually reply within a few hours on business days.
Is Google’s Mobile-Friendly Test still available?
No. Google retired the Mobile-Friendly Test tool, the Mobile-Friendly Test API and Search Console’s Mobile Usability report starting 1 December 2023, and pointed site owners to Lighthouse. Google added: “This doesn’t mean that mobile usability isn’t important for success with Google Search.”
What replaced it?
Google’s announcement named Lighthouse from Chrome. Lighthouse runs in Chrome DevTools, in PageSpeed Insights and through its API — which is what this page uses, keeping only the audits relevant to phones.
Why is font size not checked in the URL test?
Lighthouse removed its font-size audit in version 13 (October 2025), saying it no longer served a useful purpose. The local HTML check still notes font sizes below 12 px, the limit the old audit used.
What does “not applicable” mean for touch targets?
The target-size rule only tests targets that are both small and close to others. Not applicable means it found none to test, which is a good sign, not an error.
Does mobile-friendliness affect Google rankings?
Google indexes the mobile version of pages (mobile-first indexing was completed in 2023), and its page experience guidance asks whether content displays well on mobile devices. Google does not publish a separate “mobile-friendly” ranking switch.
Why do I need an API key?
The URL check calls Google’s PageSpeed Insights API from your browser, and Google no longer gives requests without a key any quota. The key is free with a Google account. The pasted-HTML check needs no key and sends nothing.
How is this different from the page speed test?
Both use the same Google API. The page speed test focuses on loading and Core Web Vitals on mobile or desktop; this page runs mobile only and adds accessibility and best-practice audits, a screenshot and the local HTML check.
Update history
New features, fixes and data refreshes for this tool, newest first.
-
· v1.0
LaunchedFirst release.
Data this tool relies on
- PageSpeed Insights / Lighthouse audits — checked 2026-11-11, reviewed every 6 months (next review by 2027-05-11)
Missing something or found an error? Tell us — requests that come up often go into the next update. All tool updates
Find the phones and pages that need work
Use your analytics to pick which pages and screen sizes to test, then watch real-user Web Vitals on mobile after each fix.