Mobile-Friendly Checker

How to Use This Tool

1. 1

   Enter the URL

   The page is fetched server-side. Only inline and embedded CSS is read, which the report tells you when most of the styling lives in an external stylesheet.

2. 2

   Check the viewport first

   Everything else is secondary. Without width=device-width a phone renders the page at desktop width and scales it down, and no other fix compensates.

3. 3

   Look at the fixed widths

   These are the usual cause of a page that has a correct viewport tag and still scrolls sideways.

4. 4

   Confirm on a real device

   Chrome DevTools device mode renders the page properly and shows what source analysis cannot. Use this to find candidates, then look at them.

What This Checks, and What It Cannot

Worth stating up front, because a mobile test that quietly overstates its reach is worse than no test.

This fetches the HTML and reads it. It does not run a browser, so it cannot lay the page out, apply external stylesheets, execute JavaScript, or measure where anything actually ends up on screen.

That rules out one check people specifically expect: tap target spacing. Whether two buttons are far enough apart depends entirely on how they render, and any tool claiming to measure that from source is guessing. So this does not report on it.

What is decidable from source turns out to cover most of the real problems anyway. The viewport declaration is in the HTML. Fixed pixel widths are in the CSS. Font sizes are in the CSS. Image dimension attributes and input types are in the markup. Those account for the large majority of pages that genuinely fail on a phone.

For the rest, Chrome DevTools device mode is the honest answer, and it is free and already installed. This tool is for finding candidates quickly across many pages; a real device is for confirming them.

The Viewport Tag

One line, and it decides more about mobile rendering than everything else combined.

Without it, mobile browsers assume the page was built for a desktop and render it at a virtual width — usually 980 pixels — then scale the result down to fit the screen. The layout is intact and everything is a third of the size it should be. Text is unreadable, links are untappable, and the only way to use the page is pinching and panning.

With `width=device-width, initial-scale=1`, the browser lays the page out at the actual screen width and your CSS can respond to it. That is the entire mechanism behind responsive design working at all.

A viewport declaring a fixed width — `width=1024`, for instance — is the same problem in a different form. The page renders at that width on every device and gets scaled. Some sites do this deliberately when they maintain a separate mobile site and serve the desktop layout unchanged, which is a legitimate if increasingly rare architecture.

Never Disable Zoom

`user-scalable=no` and `maximum-scale=1` stop people enlarging the page. Both still appear on real sites, usually copied from a template written when disabling zoom was a way to stop iOS zooming on input focus.

For anyone with low vision, zoom is not a convenience — it is how the page gets read at all. Removing it can make a site unusable, and it is a WCAG failure rather than a matter of taste.

iOS has ignored the directive since version 10 for exactly this reason. Android still honours it, so the harm is real rather than theoretical.

The problem it was working around has a proper fix: set form inputs to at least 16px and iOS stops zooming on focus by itself.

Fixed Widths Are the Usual Culprit

The most common failure on a page that already has a correct viewport tag is a single element wider than the screen.

One table, one image, one pre block, one container with `width: 1200px`. The rest of the layout is responsive and that one element forces the whole page to scroll sideways — and horizontal scrolling on a phone feels broken in a way that is hard to attribute when you are looking at it.

The distinction that matters is between `width` and `max-width`. A fixed width says the element is always this size. `max-width` says it is never wider than this, and can shrink. On a responsive page, `max-width` is almost always the one you meant.

Images are the frequent offender because a `width` attribute in the HTML behaves the same way. `max-width: 100%` in CSS is the standard defence, and it is worth applying globally rather than per image.

Text Size and Form Inputs

These are small individually and they compound. A checkout form where every field summons the wrong keyboard is measurably slower to complete, and the abandonment that follows is the kind that never appears as an error anywhere.

• Body text below about 12px needs zooming to read on a phone. 16px is the usual floor for body copy, and it is also the threshold below which iOS zooms in when an input is focused.
• An email field typed as text gets the standard keyboard with no @ key. `type="email"` gets one with @ and no shift dance.
• A phone field wants `type="tel"`, which produces a number pad rather than a full keyboard.
• A URL field wants `type="url"`, which adds a .com key and drops the space bar.
• Postcodes are alphanumeric in many countries, so `inputmode` is a better lever there than a type, and its absence is not reported as a fault.

Mobile-First Indexing

Google crawls and indexes the mobile version of a page. Not primarily — entirely, for effectively all sites. The desktop version is not what gets indexed.

The consequence people miss is about content rather than layout. If your mobile version hides sections, loads less text, or drops structured data that the desktop version has, then what is missing is missing from the index. Content behind a mobile accordion is fine, because it is in the HTML; content the mobile template never renders is not.

This makes any mobile-only content difference a ranking issue rather than a design one, and it is worth checking that the mobile and desktop versions carry the same text, the same links and the same markup.

Mobile-friendliness itself is a light ranking signal, in the same category as page experience generally. The larger effect is behavioural: on a page that is hard to use on a phone, most of your traffic leaves.

Where This Fits

Layout is one half of the mobile experience and speed is the other, and the second one is usually where the traffic is actually lost. Our Core Web Vitals Checker runs a real throttled mobile audit through Google's own API, which is a heavier and more accurate measurement than anything readable from source.

The image findings here overlap with two other checks worth running on the same page. Our Image Alt Text Auditor covers the accessibility side of the same images, and the HTTP Header Checker shows the caching that decides how a repeat visit performs on a slow connection.

Frequently Asked Questions

Related Tools