Free tool
Mobile Readiness Checker
Static checks of the viewport, responsive CSS, image widths, and font sizes in a page’s markup. Not a rendered device test.
This tool performs static mobile-readiness checks using the page’s HTML and CSS. It is not a rendered-device test and does not replace Google PageSpeed Insights or real-device testing.
The check could not be completed
Mobile readiness results
Static checks
A page can pass every check here and still be awkward on a phone, and it can fail a check that a later CSS rule already fixes. Treat a passed check as “nothing in the markup argues against it” rather than proof, and open the page on a real device before you decide.
What This Tool Does
This tool reads a page's HTML and its inline CSS and reports the things that commonly break a layout on a phone: a missing or badly configured viewport tag, no responsive media queries, fixed pixel widths wider than a typical phone screen, images and embeds with hard-coded dimensions, very small font sizes, and missing mobile conveniences such as input types and a touch icon.
It is a static check, and it is described as one throughout. It is not Google's Mobile-Friendly Test, it does not open a browser, and it does not measure how the page actually renders on a device.
How to Use It
Enter one page address. Templates matter more than individual pages here, so check one example of each layout your site uses rather than twenty pages built from the same template.
- Deal with the viewport tag first if it is flagged. Without it a phone renders the page at desktop width and scales it down, and nothing else you fix will be visible.
- Treat each fixed-width finding as a question. A 960 pixel container is a problem; a 320 pixel logo is not.
- Confirm anything flagged here by resizing a real browser window or using a phone. A static check can point at a suspicious declaration; only a rendered page proves what happens.
How the Tool Calculates or Retrieves Data
The page is fetched once from this website's server and parsed. Style tags and inline style attributes are read for media queries and width declarations. External stylesheets are not downloaded and evaluated, so a site whose responsive rules live entirely in an external file will show fewer positive signals than it deserves.
Widths are compared against a fixed reference width in the region of a common phone screen. That reference is printed with the results, so every width finding can be checked against it.
Nothing is rendered, so nothing is measured. Every result is a statement about the markup, phrased as a potential issue or a static check passed rather than as a verdict about the page.
Understanding Your Results
A problem is a declaration that will misbehave on a narrow screen as written, such as a missing viewport tag or a container fixed far wider than a phone. A potential issue is a declaration that often causes trouble but may be fine in context.
A static check passed means the markup contains what a responsive page usually contains. It does not mean the page looks right, because a page can carry every correct declaration and still overflow.
Anything the markup cannot answer is reported as unverifiable without browser rendering rather than quietly passed.
Frequently Asked Questions
Because "mobile-friendly" names a specific rendered test that this tool does not perform. Calling a static markup check by that name implies a measurement that was never taken. The address of the page is unchanged, so existing links still work.
It means the markup contains what a responsive page normally contains. It cannot mean more than that, because nothing was rendered. Open the page on a phone before you conclude anything.
Media queries are read from the page itself. Rules in an external stylesheet are not downloaded, so a fully responsive site can show no media-query evidence here. That is a limitation of the check, not a fault in the site.
No. Speed and Core Web Vitals need measurements from a real browser or from field data, and neither is available to a tool that only fetches and parses HTML.