Mobile-Friendly Tester
Free, no signup. Run this tool's seven weighted mobile-layout checks and get a 0–100 diagnostic score, plus a phone-viewport preview as separate supporting evidence.
Free, no sign-up. The analysis reads your HTML the way a mobile browser would; the screenshot renders in headless Chrome on a 390×844 iPhone-sized viewport.
Checks run from our server; we fetch the URL you enter and don't keep the results. Results are kept in a short-lived cache, not stored long-term. Anonymous aggregate stats feed our research posts; domains are counted once via an anonymized hash and never stored in the clear. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Sample report
Say you test a page whose <head> and markup look like this:
<head>
<meta name="viewport"
content="width=device-width, initial-scale=1, user-scalable=no">
<link rel="stylesheet" href="/styles/site.css"> <!-- has @media rules -->
</head>
<body>
<div style="width:960px">…fixed-width wrapper…</div>
</body>…and the tool returns a score of 78 with these checks (computed by running this page's own scorer against the signals above):
Example data — captured by running this page's own scoring engine against the markup above
Mostly mobile-friendly
https://example.com/your-page
Viewport meta tag
24/30 ptsViewport is set, but zooming is disabled — this hurts accessibility.
Content sized to viewport
9/15 pts1 element(s) with fixed widths over 400px — likely to cause horizontal scrolling.
Responsive CSS
10/20 ptsNo CSS was inspectable, so responsiveness couldn't be verified.
Legible font sizes
10/10 ptsNo inline font sizes below 12px detected.
- The linked stylesheet is the info row, not a pass — this static example never
actually fetches
/styles/site.css, so the tool honestly reports it couldn't verify responsiveness rather than assuming media queries exist. A live run against a real URL fetches up to four stylesheets to check. See what info vs. pass means ↓. - Two fixable warnings hold the score at 78:
user-scalable=noblocks pinch-zoom (drop the viewport back towidth=device-width, initial-scale=1), and thewidth:960pxwrapper will overflow a 390px screen (swap it formax-width:100%). - The three unlisted checks all passed (responsive images, page weight, no legacy plugins) — full marks there, which is why total score is 78, not lower.
- Fixing the viewport and the fixed-width wrapper — and getting the stylesheet actually inspected — would push this into the green Mobile-friendly band. Compare against the Core Web Vitals Checker if slow mobile loading is also a concern.
How to use it
- Paste the full URL of the page you want to test — a real page, not just the homepage.
The scheme is required (
https://example.com/your-page). - Complete the Turnstile check (it only appears once, on the first fresh test — cached results skip it) and press Test page.
- Read the 0–100 score and rating in the gauge, then work down the check list — failures and warnings are sorted to the top, each showing its points earned.
- Compare the checks against the phone-viewport screenshot on the right (390×844, iPhone user agent). It loads a moment after the score and is your reality check.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
390×844 viewport · iPhone user agent
This is a static-analysis check plus a real render — fast and directional. It can’t see CSS applied by JavaScript frameworks at runtime, so pair a borderline score with the screenshot: if the page looks right on the phone frame, trust your eyes.
Compare a later score
Download this free analysis as a private JSON baseline, then import it after another run to see score and failing-check changes. Snapshots stay in your browser unless you choose to save a file.
Rate this tool
What the score is made of
| Check | Threshold / points | What this free pass can confirm |
|---|---|---|
| Viewport | 30 points | width=device-width and zoom accessibility |
| Responsive CSS | 20 points | @media rules in inspected CSS |
| Fixed widths | 15 points · >400px warning | Markup-level width attributes and inline styles |
| Font sizes | 10 points · <12px warning | CSS declarations and legacy font tags |
| Tap targets / horizontal overflow | Needs a rendered layout pass | Not claimed by this free HTML score |
Viewport is 30 points
Without width=device-width, phones render your page at ~980px and shrink it to fit — every other mobile problem starts here. Disabling zoom costs points too: it’s an accessibility failure.
Layout checks
Responsive CSS (@media rules, including in external stylesheets), hard-coded widths over 400px, and sub-12px font sizes — the three classic ways a desktop layout breaks on a phone.
Delivery checks
Responsive images (srcset/<picture>), HTML page weight on mobile networks, and leftover <object>/<embed> plugin content that mobile browsers won’t run.
Checking why a page fails on phones? Start here, then read the mobile-first indexing guide and the viewport meta tag reference for the fixes.
What the results mean
The gauge colour and rating come from the total score:
- Mobile-friendly (90–100, green) — nothing structural is holding the page back on phones.
- Mostly mobile-friendly (70–89, olive) — works, but one or two checks are warnings worth fixing.
- Needs work (50–69, amber) — real problems a phone user will feel.
- Not mobile-friendly (0–49, red) — the page is likely rendering at desktop width and shrinking.
Each check carries a severity badge, colour-coded by its left border:
- Pass (green) — full or near-full credit for that check.
- Warn (amber) — partial credit; a fixable issue.
- Errors (red) — no credit; the check found a clear mobile problem.
- Info (blue) — half credit because the tool couldn’t inspect enough CSS to be sure (e.g. no stylesheet was reachable), not because the page is broken.
How it works
The score comes from a server endpoint that streams your page through a single
HTMLRewriter pass — reading the <meta name="viewport"> tag, inline
styles, width attributes, images, <object>/<embed> elements,
and the HTML byte count as the bytes flow by. It also fetches up to four linked stylesheets to look
for @media rules, then weights everything into a 0–100 total. This path is fast,
effectively free, and always runs.
The phone screenshot is a separate, metered step. Only a URL that already passed the analysis can request it, and the render draws from a shared browser-time budget with daily and monthly caps. When that budget is spent, the renderer is busy, or the page blocks headless browsers, the preview shows a calm note and your score is untouched — the two never depend on each other.
The seven checks
- Viewport meta tag — 30 pts.
width=device-widthpresent and zoom allowed. The heaviest check because every other mobile behaviour depends on it. - Responsive CSS — 20 pts. At least one
@mediarule, checked in inline<style>blocks and in the linked stylesheets. - Content sized to viewport — 15 pts. No hard-coded widths over 400px (inline style
or
widthattribute) that would force horizontal scrolling. - Legible font sizes — 10 pts. No inline font sizes under 12px and no legacy
<font size>tags. - Responsive images — 10 pts. Images use
srcset/sizesso phones don’t download desktop-sized files. - HTML page weight — 10 pts. The HTML document’s byte size — smaller loads faster on mobile networks.
- No incompatible plugins — 5 pts. No
<object>/<embed>plugin content that mobile browsers won’t run.
Limitations
The score is static analysis, so it does not run JavaScript — CSS applied at runtime
by a framework isn’t counted, which is exactly why the phone screenshot is there to cross-check.
Responsive CSS is inferred from the presence of @media rules (in the HTML and up to four
stylesheets), not from actually laying the page out, so a page with unusual responsive techniques can
read lower than it deserves. It tests one URL a public crawler can reach — login-gated or blocked
pages, and very large pages past the byte cap, are analysed only up to that cap. It also isn’t a
Core Web Vitals or tap-target-spacing test; for field performance use the
Core Web Vitals Checker.
Frequently asked questions
Google retired its Mobile-Friendly Test — is this a replacement?
Google removed the standalone Mobile-Friendly Test and the mobile-usability report in Search Console in late 2023. This tool applies its own seven-part diagnostic model. Those checks are product heuristics for finding likely mobile-layout problems, not Google eligibility criteria or a replacement for testing on real devices.
Does the test render JavaScript?
The 0–100 score comes from a static-analysis pass over the HTML and up to four stylesheets, so it does not execute JavaScript. The phone screenshot is a headless-Chrome preview and useful supporting evidence, but it is still one viewport and one rendering environment. Treat disagreements as a prompt to inspect the page and test representative real devices.
Why did I lose 30 points for the viewport tag?
The viewport check is worth 30 of the 100 points because it is the single setting every other mobile behaviour depends on. With no <meta name="viewport"> tag, phones render your page at roughly 980px wide and shrink it to fit, so text is tiny and taps miss. The fix is one line in the <head>: <meta name="viewport" content="width=device-width, initial-scale=1">. Disabling zoom (user-scalable=no or maximum-scale=1) keeps most of the credit but drops to a warning because it is an accessibility failure.
What counts as a fixed-width element?
The "Content sized to viewport" check flags any element with a hard-coded width over 400px — either an inline style:width or a width="…" attribute. Those are the widths most likely to overflow a phone screen and force horizontal scrolling. One or two is a warning; three or more is a fail. Use max-width with a percentage or relative units instead so blocks shrink on small screens.
The screenshot says "unavailable" but I still got a score — is that a bug?
No. The score and the seven checks come from the free HTML analysis, which runs first. The phone screenshot is a separate, metered render that can be skipped when a self-imposed daily or monthly cost cap is reached, when the renderer is briefly busy, or when the page blocks headless browsers. In every one of those cases the note is deliberately calm and your score is unaffected — the analysis never depends on the screenshot.
Feature requests for Mobile Friendly Tester
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
À propos de l’outil
Testez une page réelle sur sept signaux essentiels de compatibilité mobile : viewport, CSS adaptatif, largeurs fixes, taille de police, images, poids HTML et plugins. Le rapport ajoute un aperçu séparé du viewport de téléphone.
Fonctionnalités
- Score de 0 à 100 avec constats séparés pour la balise viewport, le responsive, les largeurs fixes et la typographie.
- Contrôles ciblés des images, du poids de page et des contenus de plugins incompatibles.
- Capture du viewport 390×844 pour comparer le rendu mobile à la page analysée.
- Recommandations techniques directement reliées à chaque constat et export du rapport.
Fonctionnement
Le serveur récupère l’URL fournie, examine les signaux mobiles dans le HTML et calcule un score pondéré. Chaque contrôle reçoit une gravité et une preuve, puis l’aperçu de viewport est chargé séparément pour valider visuellement la disposition.
Limites
- Le contrôle récupère une page publique et analyse le HTML jusqu’à une limite d’octets ; il ne représente pas tous les parcours connectés.
- Le score ne remplace ni un test sur de vrais appareils ni l’analyse des performances terrain Core Web Vitals.
- Les ressources chargées après interaction, les variantes géographiques et les bloqueurs peuvent modifier le rendu observé.
Questions fréquentes
Que teste exactement le score mobile ?
Il couvre la balise viewport, le CSS adaptatif, les largeurs fixes, la taille de police, les images, le poids de page et les plugins. Chaque volet conserve son propre constat.
Pourquoi tester une URL interne plutôt que la page d’accueil ?
Les modèles et composants peuvent varier selon le gabarit. Collez l’URL complète d’une page représentative, puis comparez le résultat à la capture du viewport.
Le test mesure-t-il les Core Web Vitals ?
Non. Il vérifie la compatibilité et la structure mobiles. Utilisez un contrôle CrUX ou Lighthouse pour les données de performance terrain et laboratoire.
Que signifie un avertissement ambre ?
Le signal est partiellement correct mais une amélioration est possible. Ouvrez le constat pour voir la preuve et la correction adaptée.