Technical SEO

Mobile-Friendliness & Tap-Target Auditor

Google already retired their own Mobile-Friendly Test back in 2023. Paste your page HTML (plus CSS if not inline) and this one runs seven real checks: viewport meta, fixed desktop-width layout, legible font sizes, estimated tap-target sizes, legacy plugin tags, and WCAG color contrast.

Page HTML CSS (optional — paste your stylesheet if it's not already inside a <style> tag above)

Checks that need CSS (layout width, font size, tap targets, contrast) will be skipped or marked "not enough data" if no CSS is found in the HTML or in this box.

This is a static rule-based audit — doesn't render the page like a real phone one, so tap-target and layout results are close estimates based on your CSS, not pixel-perfect measurements.

What this tool checks

Seven checks that matter for real mobile visitors and for Google's mobile-first index: a correct, non-zoom-blocking viewport tag; no hard-coded desktop-width layout; no text too small to read; comfortably-sized tap targets on links and buttons; no dead Flash/Java/marquee markup; and WCAG-compliant text contrast. Paste full page HTML (View Source can) plus your CSS if it's sitting in an external stylesheet.

How each check works

Nothing here is guessed one — every finding comes from parsing the HTML you paste (DOM) and the CSS you paste (real rule parser, unwraps @media blocks), then applies the same thresholds Google and WCAG publish.

Viewport meta tag

Checks the tag exists, uses width=device-width and initial-scale=1, and doesn't block pinch-to-zoom (user-scalable=no or maximum-scale under 2), which is a WCAG 1.4.4 fail.

Fixed desktop-width layout

Scans your CSS for structural selectors (body, .wrapper, .container, #page, ...) with a hard-coded width or min-width of 601px or more — classic sign the layout never got made responsive.

Legible font sizes

Flags any font-size declaration under 12px, the commonly-used minimum for comfortable reading on a phone screen without pinch-zooming.

Tap-target size

Estimates the rendered height of links, buttons and role="button" elements from font-size, line-height and padding (or explicit width/height), and compares against the ~44-48px guideline from Google Lighthouse and WCAG 2.5.5.

Legacy plugin content

Flags <applet>, <marquee>, <blink>, and any <embed>/<object> pointing at Flash (.swf) — none of these run in any current mobile browser already.

Color contrast (WCAG)

For any CSS rule that sets both a text color and a background color together, computes the real WCAG relative-luminance contrast ratio and checks it against the 4.5:1 (or 3:1 for large/bold text) AA minimum.

Responsive breakpoints

Counts @media rules in your CSS as a sanity signal the layout adapts to smaller screens — informational only, since a fluid layout can be responsive with zero media queries.

Frequently asked questions

Why did Google retire the Mobile-Friendly Test?

Google shut down its standalone Mobile-Friendly Test tool back in December 2023, folded mobile-friendliness into Search Console's bigger reports without a quick single-page checker anymore. This tool fills that gap with a fast, no-login, rule-based audit you can run on any pasted HTML.

Why must I paste CSS separately?

Most real pages load CSS from an external stylesheet (<link rel="stylesheet">), which this tool cannot fetch on your behalf from pasted HTML alone. Paste that stylesheet's content into the CSS box and the layout, font-size, tap-target and contrast checks all run against it.

What counts as a good tap-target size ah?

Roughly 44-48 CSS pixels tall and wide, per Google Lighthouse and WCAG 2.5.5 (Target Size). Below that, a real thumb on a real screen mis-taps neighboring links noticeably more can.

Is the tap-target estimate exact one?

No lah — it's a solid estimate from your declared font-size, line-height and padding (or explicit width/height), not a live browser render. Treat results near the 44-48px line as "verify on a real device", and results far below as a clear fail.

Does this tool send my HTML or CSS anywhere?

Your pasted HTML/CSS gets sent once, over HTTPS, to our server to run the parser (needed so the same rule engine runs for everyone), and is not stored beyond that request.