Technical SEO

Mobile-Friendliness & Tap-Target Auditor

Google retired its own Mobile-Friendly Test in 2023. Paste your page HTML (plus CSS if it is not inline) and this 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 is 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 — it does not render the page like a real phone, 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 illegibly small text; 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 works) plus your CSS if it lives in an external stylesheet.

How each check works

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

Viewport meta tag

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

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 — a classic sign the layout was never made responsive.

Legible font sizes

Flags any font-size declaration under 12px, the widely-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 it to 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.

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 that the layout adapts to smaller screens — informational, 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 in December 2023, folding mobile-friendliness into Search Console's broader reports without a quick single-page checker. This tool fills that gap with a fast, no-login, rule-based audit you can run on any pasted HTML.

Why do I need to paste CSS separately?

Most real pages load their CSS from an external stylesheet (<link rel="stylesheet">), which this tool cannot fetch on your behalf from pasted HTML alone. Paste that stylesheet's contents 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?

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 often.

Is the tap-target estimate exact?

No — it is 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 it as a clear fail.

Does this tool send my HTML or CSS anywhere?

Your pasted HTML/CSS is 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 the request.