Skip to main content
Toollyz

Search tools

Search for a command to run...

Mobile-Friendly Test

Paste a page's HTML and we run the same set of signals Google's old Mobile-Friendly Test used to check, plus a few extras: viewport meta + width=device-width, user-scalable accessibility, tap targets ≥ 44×44 px (Apple HIG), inline font-size ≥ 12px, fixed-width containers > 360px, large images without max-width:100%, plugin content (Flash/Java). Score 0-100, granular findings. 100% offline.

What is the Mobile-Friendly Test?

Mobile-Friendly Test is an HTML-paste audit that catches the most common mobile usability mistakes — the same set Google's old (sunset 2023) Mobile-Friendly Test was checking, plus a few extras. **Viewport**: must have `<meta name=viewport content='width=device-width, initial-scale=1'>`; blocking user-scalable or locking maximum-scale=1 is flagged as an accessibility warning (low-vision users can't zoom). **Tap targets**: any `<a>` or `<button>` declaring inline width or height below 44 px (Apple Human Interface Guidelines minimum). **Fonts**: any element with inline `font-size: <12px` (mobile body text should be ≥ 16 px). **Fixed widths**: containers using inline `width: <Npx>` greater than 360 px (the narrowest common phone viewport). **Responsive images**: any `<img>` wider than 480 px without `max-width: 100%` or `width: 100%`. **Plugins**: any `<object>`, `<embed>`, or `<applet>` (Flash, Java) — none of these work on mobile in 2026. Score weighted 30 pts per failure and 8 pts per warning.

How to use it

  1. Paste a page's HTML (head + body, or just head for viewport-only check).
  2. Read the headline score — 85+ is excellent, 60-85 has gaps, < 60 needs work.
  3. Use Findings to see each specific problem with element count and a one-line fix suggestion.
  4. Check the 'What we check' panel for the full list of signals.

Benefits

  • Same signals Google's Mobile-Friendly Test used before it was sunset in 2023.
  • Viewport check with width=device-width and user-scalable accessibility flag.
  • Tap-target test against Apple HIG's 44×44 px minimum.
  • Font-size test for 12 px inline minimum.
  • Fixed-width container detection (> 360 px in inline px without %).
  • Responsive image check — flags large images without max-width:100%.
  • Plugin detection — Flash/Java elements no longer work on mobile browsers.
  • 0-100 score with per-failure and per-warning weighting.
  • Granular findings with the exact element count and remediation hint.
  • Runs 100% in your browser — we check the HTML you paste, never fetch.

Frequently asked questions

Why isn't this fetching the URL like Google's version?

Toollyz is statically exported with no backend, and the browser's same-origin policy would block client-side fetches to third-party URLs. Paste the page's HTML — View Source in any browser is one keyboard shortcut away.

Does this catch all mobile-friendliness issues?

It catches the issues encoded directly in HTML attributes and inline styles. Real-world mobile-friendliness depends on layout from external CSS / JS that we don't execute. For a full audit, combine this with Chrome DevTools' Lighthouse mobile mode.

Why 44×44 px for tap targets?

Apple's Human Interface Guidelines minimum. Google's Material Design says 48 px. Both are aimed at fingertip target sizes — anything smaller is hard to hit reliably without misfires.

Why 12 px font minimum?

Below 12 px, text is hard to read on a phone without pinch-zoom. Mobile body text should be at least 16 px; we flag 12 as the lower bound where the text is unambiguously too small.

Why are tap targets and small fonts only inspecting inline styles?

External stylesheets aren't loaded — we'd need to fetch them, which the same-origin policy blocks. Inline `style=` attributes and width/height attributes are the only signals available from a paste-based audit.

What's the point of catching plugin content in 2026?

Legacy CMSes still output `<embed>` and `<object>` for video, audio, PDF previews. Some old templates embed Flash via `<object>`. None of these render on modern mobile browsers — they need to be replaced with HTML5 equivalents.

Why is the maximum-scale=1 flag a warning, not a pass?

Locking maximum-scale prevents pinch-to-zoom — a critical accessibility feature for users with low vision. Even if you don't need responsive design issues, blocking zoom violates WCAG 1.4.4.

Does it understand React / Next.js component output?

Yes — at the HTML level it doesn't matter what generated the markup. As long as you paste the rendered HTML (right-click → View Source on a hydrated page), it audits whatever's there.

What about `pointer: coarse` media queries?

Out of scope for a paste-based audit — media queries live in CSS files we can't load. Run the audit, then test with Chrome DevTools' device toolbar for the layout half.

Are my pastes saved?

Yes — the input persists in localStorage under `toollyz:mobile-friendly-input`.

Is anything uploaded?

No. Parsing and scoring run entirely in your browser.

Related tools

See all developer tools